ERROR: IDE compiles incorrect under Windows but compiles correct under Linux

[Byterra]

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:

• resetting automatically
• changing the value on the pins without the program says to
• exiting the program when it has not yet finished
• measuring a LOW pin when it is not LOW

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

[Byterra]

A late comment: I compile for theArduino Mega 2560

[ElectricRCAircraftGuy]

Related: Arduino Stack Exchange: MEGA 2560: Simple program - One analogWrite turns off the other

[matthijskooijman]

I suspect this is the same problem as https://github.com/arduino/ArduinoCore-avr/issues/339. 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.

[Byterra]

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 notifications@github.com Verzonden: zondag 3 mei 2020 09:22 Aan: arduino/Arduino Arduino@noreply.github.com CC: Byterra heijden.h@xs4all.nl; Author author@noreply.github.com 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 https://github.com/arduino/Arduino/issues/9659#issuecomment-623067819 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLZVE7ZGJHYJ2RNSRPZJNDRPULQ3ANCNFSM4KLKXLCA .

[Byterra]

platform.txt arduinoCompileTest.txt AllIn_20200108_FF.txt duration_20200503.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: 1) my adapted 'platform.txt' 2) the result log of the program compile 3) the baseline prgm AllIn_20200108 4) the derived prgm duration_20200503

To be absolutely clear: the base program that compiles fine now is AllIn_20200108 The program that still does NOT compile well: duration_20200503

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.

[matthijskooijman]

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...

[Byterra]

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 notifications@github.com Verzonden: vrijdag 22 mei 2020 21:13 Aan: arduino/Arduino Arduino@noreply.github.com CC: Byterra heijden.h@xs4all.nl; State change state_change@noreply.github.com 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 https://github.com/arduino/Arduino/issues/9659#issuecomment-632866076 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLZVE3YXJGYCSBNFQDKB43RS3FCHANCNFSM4KLKXLCA .

[matthijskooijman]

I thought of one more thing to try. The problem of https://github.com/arduino/ArduinoCore-avr/issues/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 https://github.com/arduino/arduino-cli/issues/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)

[Byterra]

Thnx, I will try it out, but need some time. Looks like something I need my full attention for 😊

Van: Matthijs Kooijman notifications@github.com Verzonden: zondag 24 mei 2020 13:11 Aan: arduino/Arduino Arduino@noreply.github.com CC: Byterra heijden.h@xs4all.nl; State change state_change@noreply.github.com 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 https://github.com/arduino/ArduinoCore-avr/issues/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 https://github.com/arduino/arduino-cli/issues/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 https://github.com/arduino/Arduino/issues/9659#issuecomment-633214844 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLZVE4K276DJ6VTQKWU3ITRTD6D7ANCNFSM4KLKXLCA .

[Byterra]

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 notifications@github.com Verzonden: zondag 24 mei 2020 13:11 Aan: arduino/Arduino Arduino@noreply.github.com CC: Byterra heijden.h@xs4all.nl; State change state_change@noreply.github.com 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 https://github.com/arduino/ArduinoCore-avr/issues/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 https://github.com/arduino/arduino-cli/issues/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 https://github.com/arduino/Arduino/issues/9659#issuecomment-633214844 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLZVE4K276DJ6VTQKWU3ITRTD6D7ANCNFSM4KLKXLCA .

[Byterra]

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:

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 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 Verzonden: zondag 24 mei 2020 13:11 Aan: arduino/Arduino CC: Byterra ; State change 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 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 , 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 , or unsubscribe . # 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}'

[matthijskooijman]

Recently, 1.8.13 was released which automatically disables --relax, fixing https://github.com/arduino/ArduinoCore-avr/issues/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.

[Byterra]

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 notifications@github.com Verzonden: vrijdag 3 juli 2020 10:13 Aan: arduino/Arduino Arduino@noreply.github.com CC: Byterra heijden.h@xs4all.nl; State change state_change@noreply.github.com 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 https://github.com/arduino/ArduinoCore-avr/issues/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 https://github.com/arduino/Arduino/issues/9659#issuecomment-653416282 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLZVE2LU6PYLVA47WQWJEDRZWHKDANCNFSM4KLKXLCA .

[matthijskooijman]

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.

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).

Thnx for all your effort. Maybe you know if there will be an entirely new version somewhere this year?

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...).

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.

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.