Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
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 reverted ASAP. -- Eric Botcazou
Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
> 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
Re: qual_union_type help
> 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 the constructor i will need to create a temporary to > hold onto it to create another component_ref? The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you know the value of the discriminant since it is assigned in the CONSTRUCTOR, so the gimplifier is indeed presumably not wired to eliminate them on its own. -- Eric Botcazou
Re: qual_union_type help
> 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 by something in the code, i.e. they can only survive in (abstract) types. There is an entire machinery in tree.c for that, called both from the front-end and middle-end in Ada. You can replace it with an explicit value (SUBSTITUTE_IN_EXPR) or you can search for it in an object (SUBSTITUTE_PLACEHOLDER_IN_EXPR). You can presumably do it through the gimplification hook. -- Eric Botcazou
Re: DWARF question about size of a variable
> 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 print on the Intel binary that shows the size > information for the variable even though the variable is optimized out? > Then by comparison on PowerPC I would expect the DWARF information > would either say the size of the variable is optimized out or there is > no information available. If you try to debug at an optimization level higher than -Og, your mileage may vary and depend on various factors; that's apparently an example where the debug info is slightly less damaged at -O3 on x86 than on PowerPC, but there are probably cases where this will be the other way around. -- Eric Botcazou
Re: New "Diving into GCC internals" section in newbies guide
> 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
Re: GCC trunk bootstrap failure on i686-w64-mingw32
> 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
Re: Possible regression in DF analysis
> 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 {cmpsi}
> (nil))
> (jump_insn 15 14 16 3 (set (pc)
> (if_then_else (gtu (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref 27)
> (pc))) "bad_cc.c":11:8 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 955630228 (nil)))
> -> 27)
> (note 16 15 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
> (jump_insn 18 16 19 4 (set (pc)
> (if_then_else (eq (reg:CC 66 cc)
> (const_int 0 [0]))
> (label_ref:DI 34)
> (pc))) "bad_cc.c":12:10 15 {condjump}
> (expr_list:REG_DEAD (reg:CC 66 cc)
> (int_list:REG_BR_PROB 365072228 (nil)))
> -> 34)
>
> Please observe the REG_DEAD note on the both jump instructions.
Passes that consume REG_DEAD/REG_UNUSED notes need to recompute them
explicitly, they are not updated on the fly.
--
Eric Botcazou
Re: Possible regression in DF analysis
> 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. Hence, it introduces the doloop_end patterns, and > renders the compare instruction (INSN 14) dead code. leading to > errors. So df_get_live_out does not contain the CC register? iv_analysis_loop_init only performs a local update of the DF information, maybe it does not cover the basic block containing insn 14 and 15? -- Eric Botcazou
Re: POWER __builtin_add_overflow/__builtin_mul_overflow with u64
> 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
Re: gcc with the new WIN32 threads fails to compile libstdc++
> 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
Re: Probe emission in fstack-clash-protection
> 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 where you *cannot* probe below the stack pointer. -- Eric Botcazou
Re: When do I need -fnon-call-exceptions?
> 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 if -fno-delete-dead-exceptions is not specified). -- Eric Botcazou
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
> 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. -- Eric Botcazou
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
> 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 switch whose name
> starts with ‘o’. %{o*} substitutes this text, including the space. Thus
> two arguments are generated.
The ultimate spec(!) is to be found in gcc.cc though, which says:
%{S*} substitutes all the switches specified to GCC whose names start
with -S. This is used for -o, -I, etc; switches that take
arguments. GCC considers `-o foo' as being one switch whose
name starts with `o'. %{o*} would substitute this text,
including the space; thus, two arguments would be generated
%{S*&T*} likewise, but preserve order of S and T options (the order
of S and T in the spec is not significant). Can be any number
of ampersand-separated variables; for each the wild card is
optional. Useful for CPP as %{D*&U*&A*}.
> It looks like this is working as documented. I checked this with the
> following spec file:
But you wouldn't have a problem if it was, would you? What happens if the '+'
is changed to another character in the line passed to the driver.
--
Eric Botcazou
[SPARC] Fix PR target/118512
This is a regression present on the mainline only, but the underlying issue
has been latent for years: the compiler and the assembler disagree on the
support of the VIS 3B SIMD ISA, the former bundling it with VIS 3 but not the
latter. IMO the documentation is not very clear, so this patch just aligns
the compiler with the assembler.
Bootstrapped/regtested on SPARC64/Solaris 11, applied on the mainline.
2025-01-18 Eric Botcazou
PR target/118512
* config/sparc/sparc-c.cc (sparc_target_macros): Deal with VIS 3B.
* config/sparc/sparc.cc (dump_target_flag_bits): Likewise.
(sparc_option_override): Likewise.
(sparc_vis_init_builtins): Likewise.
* config/sparc/sparc.md (fpcmp_vis): Replace TARGET_VIS3 with
TARGET_VIS3B.
(vec_cmp): Likewise.
(fpcmpu_vis): Likewise.
(vec_cmpu): Likewise.
(vcond_mask_): Likewise.
* config/sparc/sparc.opt (VIS3B): New target mask.
* doc/invoke.texi (SPARC options): Document -mvis3b.
2025-01-18 Eric Botcazou
* gcc.target/sparc/20230328-1.c: Pass -mvis3b instead of -mvis3.
* gcc.target/sparc/20230328-4.c: Likewise.
* gcc.target/sparc/fucmp.c: Likewise.
* gcc.target/sparc/vis3misc.c: Likewise.
--
Eric Botcazoudiff --git a/gcc/config/sparc/sparc-c.cc b/gcc/config/sparc/sparc-c.cc
index 47a22d583b6..d365da3a10b 100644
--- a/gcc/config/sparc/sparc-c.cc
+++ b/gcc/config/sparc/sparc-c.cc
@@ -52,6 +52,11 @@ sparc_target_macros (void)
cpp_define (parse_in, "__VIS__=0x400");
cpp_define (parse_in, "__VIS=0x400");
}
+ else if (TARGET_VIS3B)
+{
+ cpp_define (parse_in, "__VIS__=0x310");
+ cpp_define (parse_in, "__VIS=0x310");
+}
else if (TARGET_VIS3)
{
cpp_define (parse_in, "__VIS__=0x300");
diff --git a/gcc/config/sparc/sparc.cc b/gcc/config/sparc/sparc.cc
index a62b8033954..2196a0c4498 100644
--- a/gcc/config/sparc/sparc.cc
+++ b/gcc/config/sparc/sparc.cc
@@ -1671,6 +1671,8 @@ dump_target_flag_bits (const int flags)
fprintf (stderr, "VIS2 ");
if (flags & MASK_VIS3)
fprintf (stderr, "VIS3 ");
+ if (flags & MASK_VIS3B)
+fprintf (stderr, "VIS3B ");
if (flags & MASK_VIS4)
fprintf (stderr, "VIS4 ");
if (flags & MASK_VIS4B)
@@ -1919,19 +1921,23 @@ sparc_option_override (void)
if (TARGET_VIS3)
target_flags |= MASK_VIS2 | MASK_VIS;
- /* -mvis4 implies -mvis3, -mvis2 and -mvis. */
- if (TARGET_VIS4)
+ /* -mvis3b implies -mvis3, -mvis2 and -mvis. */
+ if (TARGET_VIS3B)
target_flags |= MASK_VIS3 | MASK_VIS2 | MASK_VIS;
- /* -mvis4b implies -mvis4, -mvis3, -mvis2 and -mvis */
+ /* -mvis4 implies -mvis3b, -mvis3, -mvis2 and -mvis. */
+ if (TARGET_VIS4)
+target_flags |= MASK_VIS3B | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
+
+ /* -mvis4b implies -mvis4, -mvis3b, -mvis3, -mvis2 and -mvis */
if (TARGET_VIS4B)
-target_flags |= MASK_VIS4 | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
+target_flags |= MASK_VIS4 | MASK_VIS3B | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
- /* Don't allow -mvis, -mvis2, -mvis3, -mvis4, -mvis4b, -mfmaf and -mfsmuld if
- FPU is disabled. */
+ /* Don't allow -mvis, -mvis2, -mvis3, -mvis3b, -mvis4, -mvis4b, -mfmaf and
+ -mfsmuld if FPU is disabled. */
if (!TARGET_FPU)
-target_flags &= ~(MASK_VIS | MASK_VIS2 | MASK_VIS3 | MASK_VIS4
- | MASK_VIS4B | MASK_FMAF | MASK_FSMULD);
+target_flags &= ~(MASK_VIS | MASK_VIS2 | MASK_VIS3 | MASK_VIS3B
+ | MASK_VIS4 | MASK_VIS4B | MASK_FMAF | MASK_FSMULD);
/* -mvis assumes UltraSPARC+, so we are sure v9 instructions
are available; -m64 also implies v9. */
@@ -11451,10 +11457,6 @@ sparc_vis_init_builtins (void)
def_builtin_const ("__builtin_vis_fmean16", CODE_FOR_fmean16_vis,
SPARC_BUILTIN_FMEAN16, v4hi_ftype_v4hi_v4hi);
- def_builtin_const ("__builtin_vis_fpadd64", CODE_FOR_fpadd64_vis,
- SPARC_BUILTIN_FPADD64, di_ftype_di_di);
- def_builtin_const ("__builtin_vis_fpsub64", CODE_FOR_fpsub64_vis,
- SPARC_BUILTIN_FPSUB64, di_ftype_di_di);
def_builtin_const ("__builtin_vis_fpadds16", CODE_FOR_ssaddv4hi3,
SPARC_BUILTIN_FPADDS16, v4hi_ftype_v4hi_v4hi);
@@ -11473,6 +11475,34 @@ sparc_vis_init_builtins (void)
def_builtin_const ("__builtin_vis_fpsubs32s", CODE_FOR_sssubv1si3,
SPARC_BUILTIN_FPSUBS32S, v1si_ftype_v1si_v1si);
+ def_builtin_const ("__builtin_vis_fhadds", CODE_FOR_fhaddsf_vis,
+ SPARC_BUILTIN_FHADDS, sf_ftype_sf_sf);
+ def_builtin_const ("__builtin_vis_fhaddd", CODE_FOR_fhadddf_vis,
+ SPARC_BUILTIN_FHADDD, df_ftype_df_df);
+ def_builtin_const ("__builtin_vis_fhsubs", CODE_FOR_fhsubsf_vis,
+ SPARC_BUILTIN_FHSUBS, sf_ftype_sf_sf);
+ def_builtin_const ("__builtin_vis_fhsubd", CODE_FOR_fhsubdf_vis,
+ SPARC_BUILTIN_FHSUBD, df_ftype_df_df);
+ def_builtin_const ("__builtin_vis_fnhadds", CODE_FOR_fnhaddsf_vis,
+ SPARC_BUILTIN_FNHADDS, sf_ftype_sf_sf);
+ def_bu
Re: Does gcc have different inlining heuristics on different platforms?
> You can see what -fuse-linker-plugin says, what gcc/auto-host.h contains > for HAVE_LTO_PLUGIN. I don't know whether the BFD linker (or mold) > supports linker plugins on windows. I do know that libiberty simple-object > does not support PE, that is, at _least_ (DWARF) debuginfo will be subpar. Here's an excerpt of a LTO compilation with -Wl,--verbose=2 on native Windows: C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `fma' definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF_IRONLY C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `main' definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `__fpclassify' definition: UNDEF, visibility: DEFAULT, resolution: RESOLVED_EXEC attempt to open C:\tmp\ccbENa6D.ltrans0.ltrans.o succeeded C:\tmp\ccbENa6D.ltrans0.ltrans.o This is with GNU ld. -- Eric Botcazou
