> From the documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
>
> %{S*}
>
> Substitutes all the switches specified to GCC whose names start
> with -S, but which also take an argument. This is used for switches like
> -o, -D, -I, etc. GCC considers -o foo as being one swit
> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this
> option is dropped in switch-c.adb and doesn't get added to the ALI file.
This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h
and it looks like the '+' character is not matched by '*' or some such.
> On x864 Linux -fasynchronous-unwind-tables is the default. That is
> probably sufficient to make your test case work.
The testcase g++.dg/torture/except-1.C you recently added to the testsuite
does not pass at all if -fnon-call-exceptions is not specified (and does not
pass with optimization
> That may ultimately be better for -fstack-check to make it more robust,
> but it still wouldn't be a viable alternative for stack clash protection
> for the reasons laid out in that blog post.
Well, -fstack-check does that when it's possible, e.g. on Windows, but it's
not on x86[_64]/Linux wher
> I'm assuming the problem also extends to the other __gthr_win32 routines as
> well, __gthr_win32_create just happens to be the first symbol it cannot
> find.
>
> Is there a way to fix this issue?
How did you configure the compiler and what version of MinGW64 do you use?
--
Eric Botcazou
> rs6000 indeed doesn't implement {,u}{add,sub,mul}v4_optab for
> any mode and thus leaves it to the generic code.
https://gcc.gnu.org/pipermail/gcc-patches/2016-October/460209.html
--
Eric Botcazou
> The problem shows in loop-doloop.c when I introduce a loop end pattern
> that replaces the first jump instruction (JUMP_INSN 15) with a pattern
> that clobbers CC reg. However, the DF doesn't look like it works as
> the doloop step cannot find the CC reg alive. Please see
> loop-doloop.c:766. Hen
> However, after this optimization I get the CC reg being dead after
> JUMP_INSN 15, which may lead to wrong code gen. Here it is the dump
> from fwprop1:
>
> (insn 14 11 15 3 (set (reg:CC 66 cc)
> (compare:CC (reg/v:SI 98 [ bytes ])
> (const_int 8 [0x8]))) "bad_cc.c":11:8 406
> So what could be causing it?
An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html
has broken --disable-sjlj-exceptions. That's now fixed.
--
Eric Botcazou
> Hope this is helpful; please let me know if you see any mistakes, or if
> there's room for improvement
Nice work! In the "inside cc1" chapter, I think that IR is usually meant for
"Intermediate Representation" rather than "Internal Representation" in this
context.
--
Eric Botcazou
> Is there dwarf information that gives the size of a variable? I have a
> test case which when run on Intel gdb can print the size of an
> optimized out variable. However on PowerPC, gdb says the size
> information for the variable is optimized out. Is there some DWARF
> information that I can
> That makes sense during construction we also know what the value of
> the discriminant is. What does the Ada front-end replace the
> placeholder_exprs with? Can it simply be the value of the discriminant
> at constructor? I haven't tried that.
Ultimately all PLACEHOLDER_EXPRs need to be replaced
> This makes sense this we can't gimplify a placeholder expression. So
> this seems that when i make a constructor for the QUAL_UNION_TYPE i
> must iterate the fields and replace the placeholder_expr to have a
> reference to the discriminant via another COMPONENT_REF. Though does
> this mean for th
> Release managers.
They certainly have authority on the timing, but not on the contents.
> Working on that right now, sorry..
OK, thanks in advance.
--
Eric Botcazou
Martin,
> The renaming patches have been just installed and I've built a few target
> compilers so far. I'll be online in ~10 hours from now so I can address
> potential issues caused by the patch.
Who approved it though? The renaming of the C files in the ada/ directory is
wrong and should be
15 matches
Mail list logo
