Re: avr-gcc still broken because of new device specific specs and libs

Probably I found the source.
It was a damn big.

------------------------------------------------------------------------
r216034 | amylaar | 2014-10-09 12:58:44 +0400 (Чт., 09 окт. 2014) | 69 lines

* config/avr/avr.opt (mmcu=): Change to have a string value.
(mn-flash=, mskip-bug, march=, mrmw): New options.
(HeaderInclude): New.
(mmcu=): Remove Var / Init clauses.
* config/avr/avr.h (DRIVER_SELF_SPECS): Translate -mmcu into a
-specs option.
(SYMBOL_FLAG_IO, SYMBOL_FLAG_ADDRESS): Define.
(ASM_OUTPUT_ALIGNED_BSS): Use avr_asm_asm_output_aligned_bss.
(SYMBOL_FLAG_IO_LOW): Define.
(avr_device_to_as, avr_device_to_ld): Don't declare.
(avr_device_to_data_start, avr_device_to_startfiles): Likewise.
(avr_device_to_devicelib, avr_device_to_sp8): Likewise.
(EXTRA_SPEC_FUNCTIONS): Don't define.
(ASM_SPEC): Translate -arch= option to -mmcu= option.
(LINK_SPEC): Translate -arch= option to -m= option.
Don't use device_to_ld / device_to_data_start.
(STARTFILE_SPEC): Now empty.
(ASM_SPEC): Add -%{mrelax: --mlink-relax}.
* config/avr/gen-avr-mmcu-specs.c: New file.
* config/avr/t-avr (gen-avr-mmcu-specs$(build_exeext)): New rule.
(s-device-specs): Likewise.
(GCC_PASSES): Add s-device-specs.
(install-driver): Depend on install-device-specs.
(install-device-specs): New rule.
* config/avr/avr.c (avr_option_override): Look up mcu arch by
avr_arch_index and provide fallback initialization for avr_n_flash.
(varasm.h): #include.
(avr_print_operand) <i>: Allow SYMBOL_REF with SYMBOL_FLAG_IO;
(avr_handle_addr_attribute, avr_eval_addr_attrib): New functions.
(avr_attribute_table): Add "io", "address" and "io_low".
(avr_asm_output_aligned_decl_common): Change type of decl to tree.
Add special handling for symbols with "io" and/or "address" attributes.
(avr_asm_asm_output_aligned_bss): New function.
(avr_encode_section_info): Set SYMBOL_FLAG_IO and SYMBOL_FLAG_ADDRESS
as appropriate.  Handle io_low attribute.
(avr_out_sbxx_branch): Handle symbolic io addresses.
(avr_xload_libgcc_p, avr_nonconst_pointer_addrspace): Use
avr_n_flash instead of avr_current_device->n_flash.
(avr_pgm_check_var_decl, avr_insert_attributes): Likewise.
(avr_emit_movmemhi): Likewise.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): Likewise.
Use TARGET_RMW instead of avr_current_device->dev_attributes.
Don't define avr_current_device->macro (that's the specfile's job).
Use TARGET_SKIP_BUG instead of avr_current_device->errata_skip.
* config/avr/avr.c (avr_2word_insn_p): Likewise.
* config/avr/avr.md (*cpse.ne): Likewise.
(mov<mode>): Use avr_eval_addr_attrib.
(cbi): Change constraint for low_io_address_operand operand to "i".
(sbi, sbix_branch, sbix_branch_bit7, insv.io, insv.not.io): Likewise.
* config/avr/predicates.md (io_address_operand):
Allow SYMBOL_REF with SYMBOL_FLAG_IO.
(low_io_address_operand): Allow SYMBOL_REF with SYMBOL_FLAG_IO_LOW.
* config/avr/avr-protos.h (avr_asm_output_aligned_decl_common):
Update prototype.
(avr_eval_addr_attrib, avr_asm_asm_output_aligned_bss): Prototype.
* config/avr/genmultilib.awk: Use -march=.
Remove Multilib matches processing.
* config/avr/t-multilib, config/avr/avr-tables.opt: Regenerate.
* config/avr/avr-arch.h: Add double include guard.
(avr_mcu_t) <library_name>: Update comment.
* config/avr/driver-avr.c (avr_device_to_as): Delete.
(avr_device_to_ld, avr_device_to_data_start): Likewise.
(avr_device_to_startfiles, avr_device_to_devicelib): Likewise.
(avr_device_to_sp8): Likewise.
* config/avr/genopt.sh:  Instead avr_mcu, emit an Enum for avr_arch.

* doc/extend.texi (io, address): Document new AVR variable attributes.
(io_low): Likewise.

------------------------------------------------------------------------

2015-02-20 23:12 GMT+03:00 Denis Chertykov <[email protected]>:
> 2015-02-20 14:56 GMT+03:00 Georg-Johann Lay <[email protected]>:
>> avr-gcc is still broken and fails to compile trivial programs:
>>
>>
>> $ avr-gcc-5.0 -mmcu=atmega8 main.c
>> /local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot
>> find dev/atmega8/crt1.o: No such file or directory
>> /local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot
>> find dev/atmega8/libdev.a: No such file or directory
>> collect2: error: ld returned 1 exit status
>>
>> Target: avr
>> Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
>> --prefix=/local/gnu/install/gcc-5.0 --disable-shared --disable-nls
>> --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld
>> target_alias=avr --enable-languages=c,c++
>>
>> gcc version 5.0.0 20150216 (experimental) (GCC)
>>
>>
>> I just updated my sources and built / installed
>>
>> - GCC configured for avr (trunk)
>> - Binutils configured for avr (master)
>> - AVR-Libc (trunk)
>>
>>
>> This situation persists for several months now, since around october '14 or
>> so.
>>
>>
>> When will this be fixed?
>>
>> Or am I missing something fundamentally like new configure options?
>>
>> More specifically:
>>
>> 1) Where is the (internal) documentation of all of this?
>>
>> 2) What must I do to get a working toolchain?
>>
>> 3) What must I do to get a working build directory, e.g. for running
>> testsuite against a freshly built and not yet installed compiler?
>>
>> 4) If this stuff is not (completely) hosted in GCC repo, what has been done
>> (e.g. GCC configury) so that older GCC versions factor out the presumably
>> now incompatible dependencies?  In particular:  How is ensured that avr-gcc
>> 4.9, 4.8 etc. will still build and work as expected with such external
>> dependencies?
>>
>> 5) Are these extensions hosted in a different place? I.e. is avr backend no
>> more supported by the FSF or forked and FSF code base messed up by
>> half-baked changes?  Or is hardware vendor simply half-hearted about state
>> of avr-gcc?
>
> Generally, I think that here (on AVR land) FSF is me.
> (or no FSF at all because I'm not FSF employee. I'm just a contributor
> and maintainer)
>
> I do not know anything about the hardware vendor.
> I never had any relationship with the ATMEL.
>
> Probably I have approved wrong or incomplete patch. (If it's not a GCC
> core patch)
> It seems that problem is in generation of `t-multilib' by `genmultilib.awk '.
>
>>
>>
>> The current situation is that it's almost impossible to contribute to
>> avr-gcc because it's impossible to run tests against patches.
>
> Why ?
>
>>
>> Applying additional patches or hacks to get it linking is actually no
>> solution because that will invalidate test results as tests won't run
>> against the intended patch but against a completely different delta.
>>
>
> If you can provide a patch to fix the bug then please do it.
>
>
>> If nobody is inclined to complete the device-specs / device-libc then I will
>> propose to revert these changes in order to get a working avr-gcc 5.0.
>
> Which changes ?
>
> If you have a solution then please provide it.
> If not then I will investigate the problem but it takes a time.
>
> Denis.
>
> PS: I'm slow because a bit demotivated for these 17 years. It's not a
> big structure. It's you, me, Joern and a few other people. No FSF, no
> ATMEL, no GCC core people.

_______________________________________________
AVR-GCC-list mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list