Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?

[Sebastian Huber]

Hello,

I noticed that the ARM libgomp is built without TLS support for RTEMS, 
since the thread-local storage detection fails, due to missing symbols 
in the crt0.o. I added the missing symbols to newlib/libc/sys/rtems/crt0.c:


https://sourceware.org/ml/newlib/2016/msg01138.html

However, this still didn't work. The reason is that during GCC build the 
random crt0.o of the prefix is used.


The configure test command line is:

/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc 
-B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc 
-B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/ 
-isystem 
/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/targ-include 
-isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include 
-B/opt/rtems-4.12/arm-rtems4.12/bin/ 
-B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem 
/opt/rtems-4.12/arm-rtems4.12/include -isystem 
/opt/rtems-4.12/arm-rtems4.12/sys-include  -mthumb -o conftest -g -O2 
conftest.c


GCC searches then in:

Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$70 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$71 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$72 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$73 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/bin/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$74 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/bin/thumb/", data=0x7fffc8c0) at 
/home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$75 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/lib/arm-rtems4.12/7.0.0/thumb/", 
data=0x7fffc8c0) at /home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$76 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Breakpoint 10, file_at_path (path=0x72a960 
"/opt/rtems-4.12/arm-rtems4.12/lib/thumb/", data=0x7fffc8c0) at 
/home/EB/sebastian_h/archive/gcc-git/gcc/gcc.c:2733

2733{
$77 = {name = 0x728d00 "crt0.o", suffix = 0x4d2257 "", name_len = 6, 
suffix_len = 0, mode = 4}


Since all previous attempts to find the file failed, it picks up 
"/opt/rtems-4.12/arm-rtems4.12/lib/thumb/crt0.o".


We have in the build tree:

find -name crt0.o
[...]
./arm-rtems4.12/thumb/newlib/crt0.o
./arm-rtems4.12/thumb/newlib/libc/crt0.o
./arm-rtems4.12/thumb/newlib/libc/sys/crt0.o
./arm-rtems4.12/thumb/newlib/libc/sys/rtems/crt0.o
[...]

In gcc.c we have:

[...]
/* Call CALLBACK for each path in PATHS, breaking out early if CALLBACK
   returns non-NULL.
   If DO_MULTI is true iterate over the paths twice, first with multilib
   suffix then without, otherwise iterate over the paths once without
   adding a multilib suffix.  When DO_MULTI is true, some attempt is made
   to avoid visiting the same path twice, but we could do better.  For
   instance, /usr/lib/../lib is considered different from /usr/lib.
   At least EXTRA_SPACE chars past the end of the path passed to
   CALLBACK are available for use by the callback.
   CALLBACK_INFO allows extra parameters to be passed to CALLBACK.

   Returns the value returned by CALLBACK.  */

static void *
for_each_path (const struct path_prefix *paths,
   bool do_multi,
   size_t extra_space,
   void *(*callback) (char *, void *),
   void *callback_info)
[...]

We have

-B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/thumb/newlib/
-B/opt/rtems-4.12/arm-rtems4.12/lib/

Its not really clear from the documentation how the search order and 
command line order is related.  The documentation doesn't mention 
multilib and multiarch options.


https://gcc.gnu.org/onlinedocs/gcc/Directory-Opt

[committed][ARM]Fix arm-netbsdelf bootstrap

[Andre Vieira (lists)]

On 02/12/16 21:16, Jeff Law wrote:
> 
> Trying to build arm-netbsdelf:
> 
> g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I/home/cygnus/law/gcc-testing/gcc/gcc
> -I/home/cygnus/law/gcc-testing/gcc/gcc/.
> -I/home/cygnus/law/gcc-testing/gcc/gcc/../include
> -I/home/cygnus/law/gcc-testing/gcc/gcc/../libcpp/include
> -I/opt/cfarm/mpc/include
> -I/home/cygnus/law/gcc-testing/gcc/gcc/../libdecnumber
> -I/home/cygnus/law/gcc-testing/gcc/gcc/../libdecnumber/dpd
> -I../libdecnumber -I/home/cygnus/law/gcc-testing/gcc/gcc/../libbacktrace
>   -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo
> /home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c
> /home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c:600:0: error:
> "TARGET_ASM_INIT_SECTIONS" redefined [-Werror]
>  #define TARGET_ASM_INIT_SECTIONS arm_asm_init_sections
> 
> In file included from
> /home/cygnus/law/gcc-testing/gcc/gcc/target-def.h:106:0,
>  from
> /home/cygnus/law/gcc-testing/gcc/gcc/config/arm/arm.c:69:
> ./target-hooks-def.h:86:0: note: this is the location of the previous
> definition
>  #define TARGET_ASM_INIT_SECTIONS hook_void_void
> 
> 
> It's referring to this section of code.  Note the placement of the
> #endif.  Looks weird, not sure if it's in the right place, should be a
> line earlier or a line later:
> 
> #if ARM_UNWIND_INFO
> #undef TARGET_ASM_UNWIND_EMIT
> #define TARGET_ASM_UNWIND_EMIT arm_unwind_emit
> 
> /* EABI unwinding tables use a different format for the typeinfo
> tables.  */
> #undef TARGET_ASM_TTYPE
> #define TARGET_ASM_TTYPE arm_output_ttype
> 
> #undef TARGET_ARM_EABI_UNWINDER
> #define TARGET_ARM_EABI_UNWINDER true
> 
> #undef TARGET_ASM_EMIT_EXCEPT_PERSONALITY
> #define TARGET_ASM_EMIT_EXCEPT_PERSONALITY arm_asm_emit_except_personality
> 
> #undef TARGET_ASM_INIT_SECTIONS
> #endif /* ARM_UNWIND_INFO */
> #define TARGET_ASM_INIT_SECTIONS arm_asm_init_sections
Hi Jeff,

Sorry about that, I meant to copy the whole thing out of the #if.

Committed this as obvious in revision r243240.

gcc/ChangeLog:

* config/arm/arm.c (TARGET_ASM_INIT_SECTIONS): Fix wrong undef
location.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
ec1f5fc5e0d9ff8ba41778ff5bb698bc50eefc5b..437da6fe3d34978e7a3a72f7ec39dc76a54d6408
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -595,8 +595,9 @@ static const struct attribute_spec arm_attribute_table[] =
 #undef TARGET_ASM_EMIT_EXCEPT_PERSONALITY
 #define TARGET_ASM_EMIT_EXCEPT_PERSONALITY arm_asm_emit_except_personality
 
-#undef TARGET_ASM_INIT_SECTIONS
 #endif /* ARM_UNWIND_INFO */
+
+#undef TARGET_ASM_INIT_SECTIONS
 #define TARGET_ASM_INIT_SECTIONS arm_asm_init_sections
 
 #undef TARGET_DWARF_REGISTER_SPAN

Re: [RFC] Support register groups in inline asm

[Andrew Senkevich]

2016-11-16 8:02 GMT+03:00 Andrew Pinski :
> On Tue, Nov 15, 2016 at 9:36 AM, Andrew Senkevich
>  wrote:
>> Hi,
>>
>> new Intel instructions AVX512_4FMAPS and AVX512_4VNNIW introduce use
>> of register groups.
>>
>> To support register groups feature in inline asm needed some extension
>> with new constraints.
>>
>> Current proposal is the following syntax:
>>
>> __asm__ (“SMTH %[group], %[single]" :
>> [single] 
>> "+x"(v0) :
>> [group]
>> "Yg4"(v1),  “1+1"(v2), “1+2"(v3), “1+3"(v4));
>>
>> where "YgN" constraint specifies group of N consecutive registers
>> (which is started from register having number as "0 mod
>> 2^ceil(log2(N))"),
>> and "1+K" specifies the next registers in the group.
>>
>> Is this syntax ok? How to implement it?
>
>
> Have you looked into how AARCH64 back-end handles this via OI, etc.
> Like:
> /* Oct Int: 256-bit integer mode needed for 32-byte vector arguments.  */
> INT_MODE (OI, 32);
>
> /* Opaque integer modes for 3 or 4 Neon q-registers / 6 or 8 Neon d-registers
>(2 d-regs = 1 q-reg = TImode).  */
> INT_MODE (CI, 48);
> INT_MODE (XI, 64);
>
>
> And then it implements TARGET_ARRAY_MODE_SUPPORTED_P. target hook?
> And the x2 types are defined as a struct of an array like:
> typedef struct int8x8x2_t
> {
>   int8x8_t val[2];
> } int8x8x2_t;

Thanks!

We have to update proposal with changing "+" symbol to "#" specifying
offset in a group (to avoid overloading the other meaning of “+”
specifying that operand is both input and output).

So current proposal of syntax is:

__asm__ (“INSTR %[group], %[single]" :
[single] "+x"(v0) :
[group]
"Yg4"(v1),  “1#1"(v2), “1#2"(v3), “1#3"(v4));

where "YgN" constraint specifies group of N consecutive registers
(which is started from register having number as "0 mod 2^ceil(log2(N))"),
and "1#K" specifies the next registers in the group.

Some other questions or comments?

What about consensus on this syntax?


--
WBR,
Andrew

Re: Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?

[Joseph Myers]

On Mon, 5 Dec 2016, Sebastian Huber wrote:

> If we assume that the command line order determines the search order, then its
> not clear why for_each_path() first iterates for all paths with the multilib
> postfix and then without. Shouldn't it iterate over all paths and check
> with/without multilib postfix in each step?

No.  The directory without the multilib postfix is generally the directory 
for another multilib, i.e. always wrong to search, and in case the library 
appears earlier in the non-multilib directories than the multilib ones, 
mixing the search paths (and there may already be some unwanted mixing 
when sysroots are involved) would result in the wrong library being 
chosen.

Unfortunately, getting rid of the search of non-multilib directories 
completely is hard.  It was removed in r96915 
.  Then this was 
reverted in .  
Furthermore, it turns out there is a case where the existing multilib 
configuration machinery cannot express things correctly without searching 
non-multilib directories.  Specifically, consider the combination of 
MULTILIB_OSDIRNAMES with sysroot suffixes.  This is used by 
config/mips/{t-mti-linux,mti-linux.h}, for example.

MULTILIB_OSDIRNAMES provides directory names used in two ways: relative to 
$target/lib/ in the GCC installation, and relative to lib/ and usr/lib/ in 
a sysroot.  For the latter, we want names such as plain ../lib64, but 
these cannot be used outside the sysroot because different multilibs would 
be mapped to the same directory.  The solution to this issue relies on 
searches without multilib suffixes: you define STARTFILE_PREFIX_SPEC 
(which used to be used more widely before MULTILIB_OSDIRNAMES was added in 
the first place) so sysroot libraries can be found by the combination of 
(sysroot, sysroot suffix, startfile prefix, *no* multilib suffix).

So while this case of MULTILIB_OSDIRNAMES with multiple sysroots makes it 
hard to eliminate the search of non-multilib directories, they should be 
searched as late as possible to reduce the risk of problems from the wrong 
libraries being found.

-- 
Joseph S. Myers
jos...@codesourcery.com