-
-
Notifications
You must be signed in to change notification settings - Fork 7k
ERROR: IDE compiles incorrect under Windows but compiles correct under Linux #9659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A late comment: I compile for theArduino Mega 2560 |
I suspect this is the same problem as arduino/ArduinoCore-avr#339. Could you try running with To do so, find the |
Hello ??Matthijs??,
Thnx for your response, it really is something that bothers me. Problem of course occurs with my Windows 10 machine. Arduino = Mega 2560, using AVRISP II.
Changed platform.txt accordingly:
## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm -fno-jump-tables
After anew compiling the program worked fine for about three quarters of an hour, equal to about 12 cycles (12 cycles from ‘void loop selection = “run” ’ ==> runTrain() and back).
Then all havoc broke lose. Especially notable was that as before pin 36 was made LOW again. Also the program made several other pins LOW without being instructed as such. But pin 36 was in the previous configuration also of interest to me because the program is nowhere instructed to make pin 36 LOW. (see the array “rijweg”).
What intrigues me is that at first the solution seemed to be there, but after a while the old problems re-occurred. Next I shut down the Arduino, compiled again on my Windows machine and up-loaded again. Same result, pins, including pin 36, were made LOW without being instructed by the program. I use the phrase “without being instructed” in the sense that from the programming and from the data present in the arrays this should not occur.
I hope to have given you an as clear as possible response, please do not hesitate to mail me for further clarification. I’d surely like to have this bug out solved !!!
Should you be interested in more detailed info about my project, you can find additional info: hvdheijd.home.xs4all.nl, under 8) Computersturing, alas only in Dutch so far.
Kind regards,
Henk van der Heijden.
Van: Matthijs Kooijman <[email protected]>
Verzonden: zondag 3 mei 2020 09:22
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; Author <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
I suspect this is the same problem as #9653 <https://github.com/arduino/Arduino/issues/9653> . Could you try running with -fno-jump-tables to see if that solves any or all of your problems?
To do so, find the platform.txt file for the used Arduino AVR core (the path should be printed somewhere at the top when compiling with verbose output) add -fno-jump-tables to the compiler.c.elf.flags line (do not forget to separate the existing stuff from the new option with a space). If you need more help, just shout.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE7ZGJHYJ2RNSRPZJNDRPULQ3ANCNFSM4KLKXLCA> .
|
platform.txt First of all my apologies for responding so late. I did what you asked, and an extremely funny thing now happens. The program I use as a sort of baseline works fine after compiling under Windows 10. Problem solved, you'd say. But nothing like it!! Another program, derived from the baseline, still has the same problem. Reed contacts read as "closed" when thay are "open", pins pinMode(nn, OUTPUT) are set LOW, where they should be, or should remain HIGH. I attach:
To be absolutely clear: the base program that compiles fine now is AllIn_20200108 Finally: the 'Serial.print' & Serial.println' now also print a time in front of the test I want to print !!! Awaiting your reply, Regards, Henk van der Heijden. |
Hey Henk, your previous reply got lost in my big TODO-list, sorry for not following up. Also note that in my previous reply, I messed up the link to the other issue, I edited that now. Your observations seem weird: The problem seems solved, but then reoccurs after running for some time (or at least, some problem occurs, possibly a different problem?). I'm wondering if there might be multiple problems here. In particular:
I had a quick look at your failing sketch, but could not find anything obviously wrong (but the code is complex, so I will certainly have missed things. I also see a lot of array indexing, which could be sensitive to overflows). In your compile log, I see some warnings, but nothing that should cause any actual problems. I'm not sure where to go from here, unfortunately. Maybe you could somehow more closely pinpoint the problem in your code, though problems like these tend to disappear when you try to shrink the code, I'm afraid... |
Hi Matthijs,
To put things as simple as I can get them
1. AllIn_20200108 compiles fine after adding the table jump statement in platform.txt
2. duration_200200503 is a derivative from AllIn; this one still shows the same problem
Problems:
1. Pin 36 is made LOW while there is never a situation in which this pin is wilfully set to LOW
2. Pin (probably) 25 or 31 is at one moment read as LOW, while no triggering is obvious from the reed-contacts
One solution I thought of, but is for me still rather complex, is to put the data in the arrays in an external memory.
Still hoping you get an idea, but I agree it is looking dark now ☹
Rgds,
Henk.
Van: Matthijs Kooijman <[email protected]>
Verzonden: vrijdag 22 mei 2020 21:13
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; State change <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
Hey Henk, your previous reply got lost in my big TODO-list, sorry for not following up. Also note that in my previous reply, I messed up the link to the other issue, I edited that now.
Your observations seem weird: The problem seems solved, but then reoccurs after running for some time (or at least, some problem occurs, possibly a different problem?).
I'm wondering if there might be multiple problems here. In particular:
* Maybe the initial problem was the jump-table problem, but there is a second problem that occurs later. That (or maybe even both) problems could be caused by errors in your code still, things like null-pointer dereferences, out-of-bounds memory writes or use-after-free errors can produce pretty random behaviour, including toggling pins.
* Maybe you do not have exactly the same AVR core and/or compiler versions on you Windows and Linux machines, which could explain the difference in behaviour? Or maybe your code does something that is undefined behaviour, then I think it might even be possible for the same compiler running on different systems to produce different results (still unlikely, but not unthinkable).
I had a quick look at your failing sketch, but could not find anything obviously wrong (but the code is complex, so I will certainly have missed things. I also see a lot of array indexing, which could be sensitive to overflows). In your compile log, I see some warnings, but nothing that should cause any actual problems.
I'm not sure where to go from here, unfortunately. Maybe you could somehow more closely pinpoint the problem in your code, though problems like these tend to disappear when you try to shrink the code, I'm afraid...
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE3YXJGYCSBNFQDKB43RS3FCHANCNFSM4KLKXLCA> .
|
I thought of one more thing to try. The problem of arduino/ArduinoCore-avr#339 actually seems to be caused by the So, you could try to disable So, to disable it, you would need to add
(I removed the |
Thnx, I will try it out, but need some time. Looks like something I need my full attention for 😊
Van: Matthijs Kooijman <[email protected]>
Verzonden: zondag 24 mei 2020 13:11
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; State change <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
I thought of one more thing to try. The problem of arduino/ArduinoCore-avr#339 <arduino/ArduinoCore-avr#339> actually seems to be caused by the --relax linker option. So far we've seen problems with jump tables, but maybe it causes problems with other situations too, maybe.
So, you could try to disable --relax. It is a bit tricky, since it is not present in platform.txt explicitly, but automatically added to compiler.c.elf.flags (which is planned to be removed, see arduino/arduino-cli#639 <arduino/arduino-cli#639> , but that won't help you now of course).
So, to disable it, you would need to add -Wl,--no-relax after the compiler.c.elf.flags, to disable it again. IOW, you could try:
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -Wl,--no-relax -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
(I removed the -fno-jump-tables again, since that should no longer be needed)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE4K276DJ6VTQKWU3ITRTD6D7ANCNFSM4KLKXLCA> .
|
Hello Matthijs,
I tried another solution first. Where in the original source I use a form of indirect addressing to obtain a value, I now use separate variables and use those variables to access the next array.
For instance:
(rijweg[spoorboek[localTeller][1]][localTel2])
then becomes
rijwegNummer = spoorboek[cycleCount] [1]; //verwijst naar rijweg regel
rijweg0 = rijweg[rijwegNummer][0]; //spoor dat aangezet moet worden uit rijweg
and then rijweg0 is a variable for instance used to do a digitalWrite with.
This leads me to the conclusion that the way the Windows compiler handles tables differs from the Linux version. So you were right in assessing that it has to do with tables, or arrays. The program works fine now, but I still am slightly irritated that now I need to do a lot of extra work, and I find my original solution so much neater.
I will try out your solution, but I have not yet clear how and where to do the change, so I will figure that out later. I’ll be in touch, stay safe.
Kind regards,
Henk.
Van: Matthijs Kooijman <[email protected]>
Verzonden: zondag 24 mei 2020 13:11
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; State change <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
I thought of one more thing to try. The problem of arduino/ArduinoCore-avr#339 <arduino/ArduinoCore-avr#339> actually seems to be caused by the --relax linker option. So far we've seen problems with jump tables, but maybe it causes problems with other situations too, maybe.
So, you could try to disable --relax. It is a bit tricky, since it is not present in platform.txt explicitly, but automatically added to compiler.c.elf.flags (which is planned to be removed, see arduino/arduino-cli#639 <arduino/arduino-cli#639> , but that won't help you now of course).
So, to disable it, you would need to add -Wl,--no-relax after the compiler.c.elf.flags, to disable it again. IOW, you could try:
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -Wl,--no-relax -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
(I removed the -fno-jump-tables again, since that should no longer be needed)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE4K276DJ6VTQKWU3ITRTD6D7ANCNFSM4KLKXLCA> .
|
Hello Matthijs,
I tried your solution, but no dice. Still pins are made LOW where they shoud have remained HIGH.
This was what I understand from your mail:
<start txt>
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -W1,--no-relax -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
<end txt>
Still, compiler “says no”: avr-gcc: error: unrecognized command line option '-W1,--no-relax'; did you mean '-mno-relax'?
I tried to change to ‘-mno’ instead of ‘–-no’, expecting a typo.
Then there was another error, the ‘W1’ needed to be removed. After that the compiler compiled. But my problem was not solved alas.
To be complete, I attached the version I could compile the source with.
Conducted test: I tried the same source under both the Linux and the Windows compiler, and as usual the code compiled under Linux has no problem and works fine, but the Windows compiled version still did unexplainable (at least to me) things. I think the proper expression now is “how now brown cow?”
As I mailed to you earlier, I did resolve the problem in another way by having added extra variables that read data from one array, and then use these to read another one. But I was quite enthousastic bout that indirect addressing. You call jump tables I understand now.
Hope there will be a solution shortly when there is a new release or, you have still another solution ??.
Kind regards,
Henk.
Van: Matthijs Kooijman <[email protected]>
Verzonden: zondag 24 mei 2020 13:11
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; State change <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
I thought of one more thing to try. The problem of arduino/ArduinoCore-avr#339 <arduino/ArduinoCore-avr#339> actually seems to be caused by the --relax linker option. So far we've seen problems with jump tables, but maybe it causes problems with other situations too, maybe.
So, you could try to disable --relax. It is a bit tricky, since it is not present in platform.txt explicitly, but automatically added to compiler.c.elf.flags (which is planned to be removed, see arduino/arduino-cli#639 <arduino/arduino-cli#639> , but that won't help you now of course).
So, to disable it, you would need to add -Wl,--no-relax after the compiler.c.elf.flags, to disable it again. IOW, you could try:
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -Wl,--no-relax -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
(I removed the -fno-jump-tables again, since that should no longer be needed)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE4K276DJ6VTQKWU3ITRTD6D7ANCNFSM4KLKXLCA> .
# Arduino AVR Core and platform.
# ------------------------------
#
# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
name=Arduino AVR Boards
version=1.8.2
# AVR compile variables
# ---------------------
compiler.warning_flags=-w
compiler.warning_flags.none=-w
compiler.warning_flags.default=
compiler.warning_flags.more=-Wall
compiler.warning_flags.all=-Wall -Wextra
# Default "compiler.path" is correct, change only if you want to override the initial value
compiler.path={runtime.tools.avr-gcc.path}/bin/
compiler.c.cmd=avr-gcc
compiler.c.flags=-c -g -Os {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -MMD -flto -fno-fat-lto-objects
compiler.c.elf.flags={compiler.warning_flags} -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections
compiler.c.elf.cmd=avr-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -flto -MMD
compiler.cpp.cmd=avr-g++
compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto
compiler.ar.cmd=avr-gcc-ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=avr-objcopy
compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
compiler.elf2hex.flags=-O ihex -R .eeprom
compiler.elf2hex.cmd=avr-objcopy
compiler.ldflags=
compiler.size.cmd=avr-size
# This can be overridden in boards.txt
build.extra_flags=
# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=
# AVR compile patterns
# --------------------
## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.S.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.S.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Create archives
# archive_file_path is needed for backwards compatibility with IDE 1.6.5 or older, IDE 1.6.6 or newer overrides this value
archive_file_path={build.path}/{archive_file}
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{archive_file_path}" "{object_file}"
## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mno-relax -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
## Create output files (.eep and .hex)
recipe.objcopy.eep.pattern="{compiler.path}{compiler.objcopy.cmd}" {compiler.objcopy.eep.flags} {compiler.objcopy.eep.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.eep"
recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"
## Save hex
recipe.output.tmp_file={build.project_name}.hex
recipe.output.save_file={build.project_name}.{build.variant}.hex
## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.text|\.data|\.bootloader)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.bss|\.noinit)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
## Preprocessor
preproc.includes.flags=-w -x c++ -M -MG -MP
recipe.preproc.includes="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.includes.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}"
preproc.macros.flags=-w -x c++ -E -CC
recipe.preproc.macros="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} {preproc.macros.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{preprocessed_file_path}"
# AVR Uploader/Programmers tools
# ------------------------------
tools.avrdude.path={runtime.tools.avrdude.path}
tools.avrdude.cmd.path={path}/bin/avrdude
tools.avrdude.config.path={path}/etc/avrdude.conf
tools.avrdude.network_cmd={runtime.tools.arduinoOTA.path}/bin/arduinoOTA
tools.avrdude.upload.params.verbose=-v
tools.avrdude.upload.params.quiet=-q -q
# tools.avrdude.upload.verify is needed for backwards compatibility with IDE 1.6.8 or older, IDE 1.6.9 or newer overrides this value
tools.avrdude.upload.verify=
tools.avrdude.upload.params.noverify=-V
tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} {upload.verify} -p{build.mcu} -c{upload.protocol} "-P{serial.port}" -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
tools.avrdude.program.params.verbose=-v
tools.avrdude.program.params.quiet=-q -q
# tools.avrdude.program.verify is needed for backwards compatibility with IDE 1.6.8 or older, IDE 1.6.9 or newer overrides this value
tools.avrdude.program.verify=
tools.avrdude.program.params.noverify=-V
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"
tools.avrdude.erase.params.verbose=-v
tools.avrdude.erase.params.quiet=-q -q
tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m
tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m
tools.avrdude_remote.upload.pattern=/usr/bin/run-avrdude /tmp/sketch.hex {upload.verbose} -p{build.mcu}
tools.avrdude.upload.network_pattern="{network_cmd}" -address {serial.port} -port {upload.network.port} -sketch "{build.path}/{build.project_name}.hex" -upload {upload.network.endpoint_upload} -sync {upload.network.endpoint_sync} -reset {upload.network.endpoint_reset} -sync_exp {upload.network.sync_return}
# USB Default Flags
# Default blank usb manufacturer will be filled in at compile time
# - from numeric vendor ID, set to Unknown otherwise
build.usb_manufacturer="Unknown"
build.usb_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid} '-DUSB_MANUFACTURER={build.usb_manufacturer}' '-DUSB_PRODUCT={build.usb_product}'
|
Recently, 1.8.13 was released which automatically disables
I think you misunderstood: Jump tables are internally generated by the compiler when you use a |
Thnx for your reply.
Removed old version. Cleared as far as possible registry, installed 1.8.13, and even faster than before the same problem occurred, pins were set LOW, while they should have remained HIGH.
Hopefully a new compiler will come some day. So I’ll keep on using the work around by reading data into variables and not use array values directly into another array.
Thnx for all your effort. Maybe you know if there will be an entirely new version somewhere this year?
It would be interesting to compare the compiled Linux version with the compiled Windows version. On Linux I use (Arduino2:1.0.5+dfsg2-4.1), and at the moment I do not dare to upgrade. The Windows verson is able to export the machine code. The Linux version I use does not.
Regards,
Henk.
Van: Matthijs Kooijman <[email protected]>
Verzonden: vrijdag 3 juli 2020 10:13
Aan: arduino/Arduino <[email protected]>
CC: Byterra <[email protected]>; State change <[email protected]>
Onderwerp: Re: [arduino/Arduino] ERROR: IDE compiles incorrect under Windows but compiles correct under Linux (#9659)
Recently, 1.8.13 was released which automatically disables --relax, fixing arduino/ArduinoCore-avr#339 <arduino/ArduinoCore-avr#339> . You could try upgrading and see if that helps, no further changes needed (you do need to revert your changes to platform.txt of course).
As I mailed to you earlier, I did resolve the problem in another way by having added extra variables that read data from one array, and then use these to read another one. But I was quite enthousastic bout that indirect addressing. You call jump tables I understand now.
I think you misunderstood: Jump tables are internally generated by the compiler when you use a switch statement. Arrays used in your own code are not those and should be unaffected by this problem.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#9659 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLZVE2LU6PYLVA47WQWJEDRZWHKDANCNFSM4KLKXLCA> .
|
Hm, that suggests that you problem is really a different one than I had thought it was. Maybe another compiler bug then, or maybe some problem in your code after all, maybe you have a bug that triggers undefined behaviour and different compiler versions behave differently with that (as they're allowed to). The code too complex for me too tell. I'm not sure if I have any further suggestions for debugging this, though. Or maybe one: Did you try enabling warnings in the preferences? If there is indeed undefined behaviour, the compiler might be raising a warning (which are hidden by default, unfortunately).
Not sure, I think that gcc for AVR has not always been quick to update, and I think development has nearly halted in most recent versions (there was a bountysource about migrating AVR to a new backend in gcc, otherwise it might even be removed in the near future...).
Oh, that's an ancient version. I hadn't realized that when you first posted this, but that probably means the problem is not Linux vs Windows, but just old compiler vs new compiler. Normally, I would recommend people upgrade from that ancient version, but given it works for you now, I'll refrain from that. |
Compiling under Linux results in a fine working program.
When I compile the same source under W10 the program has a lot of faults like:
To investigate this, I used two different Windows 10 laptops, also I did a clean install again on one of them, IDE version 1.8.10.
For Linux I use an older laptop with Ubuntu 18.04.3 LTS and IDE 2:1.05+dfsg2-4.1 is used.
Source:
AllIn_2020_Base_Keep.TXT
The text was updated successfully, but these errors were encountered: