[Bug c/105120] __OPTIMIZE__ macro incorrectly defined when using pragma(optimize) with push_options/pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105120
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2022-04-01
--- Comment #1 from Richard Biener ---
This is known and hard to fix - it also applies to other macros whose
definition depends on optimization flags (like from -ffast-math). When you run
into such
issue the workaround is to split the translation units at optimization flag
boundary.
It's odd that we manage to sneak in __OPTIMIZE__, I didn't know we do. Same
applies to -ffast-math it seems:
_Pragma("GCC push_options")
#ifndef __FAST_MATH__
_Pragma("GCC optimize(\"fast-math\")")
#endif
inline void noop() {}
_Pragma ("GCC pop_options")
#ifdef __FAST_MATH__
#pragma message("__FAST_MATH__ defined")
#endif
so pop_options fails to pop the macro definitions.
[Bug c/105120] __OPTIMIZE__ macro incorrectly defined when using pragma(optimize) with push_options/pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105120 --- Comment #2 from Richard Biener --- c_cpp_builtins_optimize_pragma does the macro adjustment, but in handle_pragma_pop_options it doesn't get called because the guarding condition if (p->optimize_binary != optimization_current_node) is false.
[Bug libstdc++/105118] Why is unexpected::value() named error() in libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- I think currently libstdc++ also implements P2549R0 (https://wg21.link/p2549r0). Let's suspend the issue until whether P2549R0 is accepted or rejected is determined.
[Bug c/105120] __OPTIMIZE__ macro incorrectly defined when using pragma(optimize) with push_options/pop_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105120
--- Comment #3 from Andrey Turkin ---
Personally I don't care much about implications of bug 48026; the issue that
affects me is pop_options leaking some state changed by pragmas inside
push_options/pop_options, namely macros. That sample was derived from a
real-world example there we use a third-party library (fmt) which does this
optimize thing in its core header - it defines a number of inline functions and
supposedly the optimize makes resulting debug binaries smaller (not sure how
optimize override works with regard to inline functions but they must've done
this for a reason); that library is included into our logging header which is
used pretty much everywhere, and it is PCHed. Which means that we are getting
inconsistent compiler state everywhere in a debug build, and there is no way to
separate it into its own TU.
I think pop_options should roll back these compiler-defined macros; in the
meantime there is a workaround - one can explicitely wrap such
push_options/pop_options block with push_macro("__OPTIMIZE__")/pop_macro pair.
[Bug lto/105121] New: ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 Bug ID: 105121 Summary: ice in bp_unpack_string Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 52731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52731&action=edit x86 object module Recent gcc does this: $ gcc src/bin/tolua.o src/bin/toluabind.o lto1: internal compiler error: Segmentation fault 0xc94f99 crash_signal(int) ../../trunk.git/gcc/toplev.cc:322 0x772070 bp_unpack_string(data_in*, bitpack_d*) ../../trunk.git/gcc/data-streamer-in.cc:112 0xb89903 cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*) /home/dcb/gcc/working/gcc/options-save.cc:13503 0xf1b7e0 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) ../../trunk.git/gcc/tree-streamer-in.cc:558 0xad7186 lto_read_tree_1(lto_input_block*, data_in*, tree_node*) The problem first seems to occur sometime between git hash 4cb935cb69f12088 and 1c7b110e1e44da0c.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 --- Comment #1 from David Binderman --- Created attachment 52732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52732&action=edit x86 object module
[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052 --- Comment #10 from Jiu Fu Guo --- While would we keep this open for a while to see if this issue occurs again.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #35 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e0ce885851dfd926c0cfe6f23a2debc87ea2bb9d
commit r12-7951-ge0ce885851dfd926c0cfe6f23a2debc87ea2bb9d
Author: Jakub Jelinek
Date: Fri Apr 1 11:49:40 2022 +0200
testsuite: Add further zero size elt passing tests [PR102024]
As discussed in PR102024, zero width bitfields might not be the only ones
causing ABI issues at least on mips, zero size arrays or (in C only) zero
sized (empty) structures can be problematic too.
The following patch adds some coverage for it too.
Tested on x86_64-linux with
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=gcc
ALT_CXX_UNDER_TEST=g++ --target_board=unix\{-m32,-m64\} compat.exp=pr102024*'
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=clang
ALT_CXX_UNDER_TEST=clang++ --target_board=unix\{-m32,-m64\}
compat.exp=pr102024*'
with gcc/g++ 10.3 and clang 11. Everything but (expectedly)
FAIL: gcc.dg/compat/pr102024 c_compat_x_tst.o-c_compat_y_alt.o execute
FAIL: gcc.dg/compat/pr102024 c_compat_x_alt.o-c_compat_y_tst.o execute
for -m64 ALT_CC_UNDER_TEST=gcc passes.
2022-04-01 Jakub Jelinek
PR target/102024
* gcc.dg/compat/pr102024_test.h: Add further tests with zero sized
structures and arrays.
* g++.dg/compat/pr102024_test.h: Add further tests with zero sized
arrays.
[Bug tree-optimization/104645] [12 Regression] i ? i % 2 : 0 not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d9c03fc27d8147a9401a29739694b214df48a9a2 commit r12-7952-gd9c03fc27d8147a9401a29739694b214df48a9a2 Author: Jakub Jelinek Date: Fri Apr 1 11:50:41 2022 +0200 phiopt: Improve value_replacement [PR104645] The following patch fixes the P1 regression by reusing existing value_replacement code. That function already has code to handle simple preparation statements (casts, and +,&,|,^ binary assignments) before a final binary assignment (which can be much wider range of ops). When we have e.g. if (y_3(D) == 0) goto ; else goto ; : y_4 = y_3(D) & 31; _1 = (int) y_4; _6 = x_5(D) r<< _1; : # _2 = PHI the preparation statements y_4 = y_3(D) & 31; and _1 = (int) y_4; are handled by constant evaluation, passing through y_3(D) = 0 initially and propagating that through the assignments with checking that UB isn't invoked. But the final _6 = x_5(D) r<< _1; assign is handled differently, either through neutral_element_p or absorbing_element_p. In the first function below we now have: [local count: 1073741824]: if (i_2(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: _3 = i_2(D) & 1; iftmp.0_4 = (int) _3; [local count: 1073741824]: # iftmp.0_1 = PHI where in GCC 11 we had: : if (i_3(D) != 0) goto ; [INV] else goto ; [INV] : i.1_1 = (int) i_3(D); iftmp.0_5 = i.1_1 & 1; : # iftmp.0_2 = PHI Current value_replacement can handle the latter as the last stmt of middle_bb is a binary op that in this case satisfies absorbing_element_p. But the former we can't handle, as the last stmt in middle_bb is a cast. The patch makes it work in that case by pretending all of middle_bb are the preparation statements and there is no binary assign at the end, so everything is handled through the constant evaluation. We simply set at the start of middle_bb the lhs of comparison virtually to the rhs, propagate it through and at the end see if virtually the arg0 of the PHI is equal to arg1 of it. For GCC 13, I think we just should throw away all the neutral/absorbing element stuff and do the constant evaluation of the whole middle_bb and handle that way all the ops we currently handle in neutral/absorbing element. 2022-04-01 Jakub Jelinek PR tree-optimization/104645 * tree-ssa-phiopt.cc (value_replacement): If assign has CONVERT_EXPR_CODE_P rhs_code, treat it like a preparation statement with constant evaluation. * gcc.dg/tree-ssa/pr104645.c: New test.
[Bug tree-optimization/104645] [12 Regression] i ? i % 2 : 0 not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 --- Comment #2 from Richard Biener --- Are you sure you have object files compiled with the same compiler as you link with?
[Bug target/105122] New: [12 Regression] Testsuite failures since r12-7931 on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105122
Bug ID: 105122
Summary: [12 Regression] Testsuite failures since r12-7931 on
i686-linux
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Starting with r12-7931-gb8207ad367174df5f2e2fdf3305c97ed227d8f78 I'm seeing on
i686-linux (or x86_64-linux with
RUNTESTFLAGS='--target_board=unix/-m32/-mno-sse'
testing:
+FAIL: gcc.dg/memcpy-6.c (test for warnings, line 25)
+FAIL: gcc.dg/memcpy-6.c scan-tree-dump-not optimized "memcpy"
+FAIL: gcc.dg/memcpy-6.c scan-tree-dump-not optimized "memmove"
+FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "_not_eliminated_"
0
+FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "strlen" 0
+FAIL: gcc.dg/strlenopt-80.c scan-tree-dump-times optimized "failure_on_line
(" 0
+FAIL: gcc.dg/ipa/remref-7.c scan-ipa-dump inline "Removed a reference"
Haven't checked if those tests existed before the
r12-3482-g5f6a6c91d7c592cb49f7c519f289777eac09bb74 commit.
[Bug target/105122] [12 Regression] Testsuite failures since r12-7931 on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105122 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |12.0 CC||rguenth at gcc dot gnu.org
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810
--- Comment #9 from Richard Biener ---
Btw, while in the abstract machine sense for the testcase 'i' is never actually
read the SSA GIMPLE already exposes an uninitialized read of it:
void k ()
{
...
:
a.9_3 = a;
if (a.9_3 >= 0)
goto ; [INV]
else
goto ; [INV]
:
i_25 = i_13 + 1;
h.10_4 = h;
_5 = h.10_4 + -1;
h = _5;
:
# i_13 = PHI
a.11_6 = a;
if (a.11_6 != 0)
goto ; [INV]
else
goto ; [INV]
that's because for
while (a) {
}
which is not entered because 'a' is zero we have the PHI node for 'i' since
the condition is part of the loop and SSA form requires us to represent
the value of 'i' on the entry edge.
That means those uses are not real uses and thus do not invoke undefined
behavior (at the point of execution of the PHI node). That would be
different from
tem_2 = i_20(D);
# tem_3 = PHI
but copy propagation will turn this into the other case (but that would
be conservatively OK).
Note that for the testcase IVOPTs inserts the rewritten uses in a place
where i is now used unconditionally turning
if (a.9_15 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 139545903]:
goto ; [100.00%]
[local count: 564526613]:
i_17 = i_16 + 1;
_19 = h_lsm.23_10 + -1;
[local count: 634299566]:
# i_16 = PHI
# h_lsm.23_10 = PHI
if (a.9_15 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 69772953]:
into
if (a.9_15 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 139545903]:
goto ; [100.00%]
[local count: 564526613]:
i_17 = i_16 + 1;
[local count: 634299566]:
# i_16 = PHI
_28 = (unsigned int) b.7_13;
_41 = (unsigned int) i_24(D);
_51 = _28 + _41;
_22 = (unsigned int) i_16;
_48 = -_22;
_49 = _48 + _51;
h_lsm.23_10 = (int) _49;
if (a.9_15 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 69772953]:
when it eliminates the h_lsm.23 IV and rewrites it in terms of i.
[Bug middle-end/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- I've posted a(nother) patch.
[Bug target/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 --- Comment #14 from rsandifo at gcc dot gnu.org --- FWIW, I agree with Vlad that this isn't an RA problem. Some aarch64 instruction patterns are accepting operands that will inevitably require a reload. In principle we could tighten the predicates so that we reject these kinds of subreg for operands that only allow GPRs (not FPRs). But that just shifts the problem elsewhere. Some of these patterns do support w->w, so the net effect would be to lose out on some useful combinations without fixing the actual problem. I guess we should use an STV-like pass to do vector vs. scalar instruction selection, with that pass being the one that forces separate moves when (subreg:xI (reg:VnxI R) 0) occurs in a “scalar” instruction. Would be good to make it relatively target-independent though. So IMO we should fix RTL representation problem that Andrew pointed out in comment 7 as the P1 fix, then accept the other cases as a P2 regression caused by bigger improvements elsewhere.
[Bug libstdc++/105118] Why is unexpected::value() named error() in libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-04-01 Status|UNCONFIRMED |SUSPENDED --- Comment #2 from Jonathan Wakely --- (In reply to Jiang An from comment #1) > I think currently libstdc++ also implements P2549R0 Correct. It's already been approved by LEWG and I see no reason to think it won't be approved by the full committee.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-01 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING
[Bug target/105122] [12 Regression] Testsuite failures since r12-7931 on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105122 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-04-01 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||missed-optimization Target||i?86-*-* --- Comment #1 from Richard Biener --- I will have a look. +FAIL: gcc.dg/memcpy-6.c (test for warnings, line 25) +FAIL: gcc.dg/memcpy-6.c scan-tree-dump-not optimized "memcpy" +FAIL: gcc.dg/memcpy-6.c scan-tree-dump-not optimized "memmove" fold_copy_8 and fold_move_8 are no longer folded, that's to be expected with MOVE_MAX and DImode types not being involved directly. The r12-3482 change would have newly folded those. fold_move_8 is also not expanded inline by RTL expansion. GCC 11 seems to fold both. The gcc.dg/ipa/remref-7.c one is probably spurious (it's a new testcase).
[Bug target/105123] New: wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123
Bug ID: 105123
Summary: wrong code with -m32 -mtune=i686 and
__builtin_shuffle()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 52733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52733&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -m32 -mtune=i686 testcase.c
$ ./a.out
Aborted
v[] is { 0, 0, 0, 0 }
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7935-20220331110233-g90533de067d-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7935-20220331110233-g90533de067d-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220331 (experimental) (GCC)
[Bug target/105122] [12 Regression] Testsuite failures since r12-7931 on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105122
--- Comment #2 from Richard Biener ---
Ah, in GCC 11 we had
/* Max number of bytes we can move from memory to memory
in one reasonably fast instruction. */
#define MOVE_MAX 16
while in GCC 12 it is now
/* Max number of bytes we can move from memory to memory in one
reasonably fast instruction, as opposed to MOVE_MAX_PIECES which
is the number of bytes at a time which we can move efficiently.
MOVE_MAX_PIECES defaults to MOVE_MAX. */
#define MOVE_MAX \
((TARGET_AVX512F \
&& (ix86_move_max == PVW_AVX512 \
|| ix86_store_max == PVW_AVX512)) \
? 64 \
: ((TARGET_AVX \
&& (ix86_move_max >= PVW_AVX256 \
|| ix86_store_max >= PVW_AVX256)) \
? 32 \
: ((TARGET_SSE2 \
&& TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
&& TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
? 16 : UNITS_PER_WORD)))
and UNITS_PER_WORD is now 4. Not sure if that was a concious decision?
I'm not sure we want to "cheat" here. For memcpy-6.c we have sth like
char a[32];
void fold_copy_8 (void)
{
__builtin_memcpy (a + 3, a, 8);
}
where if we'd try to use 'long long' we'd succeed (since 'a' is properly
aligned). We'd have to use lang_hook.types.types_for_mode to not get
too large types but even with that we'll happily use __int128_t on
i?86 with -mno-sse when copying 16 bytes. The idea of using larger
types than MOVE_MAX was to restrict that to the cases where we do say
__int128_t tem;
memcpy (&tem, a, 16);
and thus the large type is used in the source already (and is > MOVE_MAX).
Similarly for 'double' on i?86 where we'd use DImode. For the sake
of removing abstraction. But the gcc.dg/memcpy-6.c testcase should be
about RTL expansion (with the known lack of handling of memmmove).
Btw, lang_hooks.types.type_for_mode reveals __int128_t via
#if HOST_BITS_PER_WIDE_INT >= 64
if (mode == TYPE_MODE (intTI_type_node))
return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
#endif
even though we have
(gdb) p int_n_enabled_p
$2 = {false}
(gdb) p int_n_data[0]
$3 = {bitsize = 128, m = TImode}
of course __int128_t != unsigned __attribute__((mode(TI))), but ...
[Bug target/105123] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123 Martin Liška changed: What|Removed |Added Keywords||needs-bisection CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-01 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started in between 4.8.x and 4.9.
[Bug target/105123] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123 --- Comment #2 from Jakub Jelinek --- Yeah, I'll bisect.
[Bug debug/105124] New: -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105124
Bug ID: 105124
Summary: -Og loses DWARF value for a reassigned variable that
is kept instead by other optimization levels
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C code, variable l_62 appears as optimized out at line 6,
where it is assigned again with the same value and used in the assignment of
global variable a. The variable is then available at line 8 with its correct
value 6 coming from the update at line 7.
This behavior only occurs when the optimization level is Og, while at -O1 and
higher optimization levels the variable is always visible with a correct value
available.
Interestingly, if we assign l_62 for instance with 2 at line 4, then the issue
is no longer present at Og and the value 2 is displayed at line 6 (just like at
-O1/O2/O3). We also note that, in this case, at -O1/-Og the DWARF info contains
values 0 and 6, while at -O2/-O3 also value 0 which is in use only between line
6 and 7.
We provide below a detailed analysis on x64.
$ cat a.c
short a;
int foo1() { return 0; }
short foo0(int d) {
int e, f = 11, l_62 = 0;
e = foo1();
a = f | (l_62 = e) >= d;
l_62 = 6;
return d;
}
int main() { foo0(0); }
GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
$ gdb --version
GNU gdb (GDB) 11.2
GDB trace:
$ gcc -Og -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x40048f: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/4/reduce/opt
Breakpoint 1, foo0 (d=d@entry=0) at a.c:6
6 a = f | (l_62 = e) >= d;
(gdb) info loc
e =
f = 11
l_62 =
(gdb) n
8 return d;
(gdb) info loc
e =
f = 11
l_62 = 6
ASM of foo0 function:
0040048c :
40048c: 53 push %rbx
40048d: 89 fb mov%edi,%ebx
40048f: 66 c7 05 92 0b 20 00movw $0xb,0x200b92(%rip)#
60102a
400496: 0b 00
400498: 89 d8 mov%ebx,%eax
40049a: 5b pop%rbx
40049b: c3 retq
DWARF at -Og:
0x00c9: DW_TAG_variable
DW_AT_name("l_62")
DW_AT_decl_file ("/home/stepping/4/reduce/a.c")
DW_AT_decl_line (4)
DW_AT_decl_column (0x12)
DW_AT_type(0x007f "int")
DW_AT_location(0x0010:
[0x0040048f, 0x0040048f): DW_OP_lit0,
DW_OP_stack_value
[0x00400498, 0x0040049c): DW_OP_lit6,
DW_OP_stack_value)
DW_AT_unknown_2137(0x000c)
>From a quick analysis of DWARF symbols, the problem seems to be in the location
definition of the variable. The first entry is an empty range when it should
probably include the instruction at 40048f which is associated with line 6. We
tried to manually patch the executable file from -Og by setting the first entry
of the location [0x0040048f, 0x0040048f) to
[0x0040048f, 0x00400498). After the change, the variable is
displayed.
At -O1 and higher optimization levels, the first entry of the DWARF location
info contains the correct range that includes the ASM instruction associated
with line 6.
DWARF at O1 (identical at O2/O3, only addresses change):
0x00a1: DW_TAG_variable
DW_AT_abstract_origin (0x00e2 "l_62")
DW_AT_location (0x0020:
[0x004003a0, 0x004003ac): DW_OP_lit0,
DW_OP_stack_value
[0x004003ac, 0x004003af): DW_OP_lit6,
DW_OP_stack_value)
DW_AT_unknown_2137 (0x001c)
If we interpret the code correctly, foo1 is always
inlined/constant-propagated, while foo0 is inlined at other optimization levels
but not at -Og.
We have also tested older gcc versions (6.4, 7.5, 8.4, 9.3, 10.3, 11.1) and the
variable l_62 is always optimized out on line 6 at each optimization level.
The only exception is gcc-7 that produces (only at Og) a wrong debug
information, since at line 6 l_62 has 6 as current value.
[Bug debug/105124] -Og loses DWARF value for a reassigned variable that is kept instead by other optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105124 --- Comment #1 from Cristian Assaiante --- We suspect this may be related to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108 but this time the behaviors at -O1 and -Og are different
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 --- Comment #3 from David Binderman --- (In reply to Richard Biener from comment #2) > Are you sure you have object files compiled with the same compiler as you > link with? I just compiled it again. Yes, I have the same compiler. It looks like a mismatch in LTO readers and writers to me. Would the .i file that is upstream of the .o file help ?
[Bug debug/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105041 Peter Bergner changed: What|Removed |Added Priority|P3 |P4 --- Comment #4 from Peter Bergner --- Given this only affects 32-bit BE compiles that use the uncommonly used option -frename-registers, I'm dropping the importance to P4.
[Bug c++/105125] New: Bogus and Misleading Warning: Packed attribute is unnecessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105125
Bug ID: 105125
Summary: Bogus and Misleading Warning: Packed attribute is
unnecessary.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Kimon.Hoffmann at lawo dot com
Target Milestone: ---
GCC erroneously declares a packed attribute on a struct member as unnecessary,
while it clearly isn't.
Reproducer:
-- 8< --
#include
struct A
{
std::uint32_t i;
};
struct B
{
std::uint64_t i;
};
struct C
{
A a;
B b;
};
struct D
{
A a [[gnu::packed]];
B b;
};
struct E
{
A a;
B b [[gnu::packed]];
};
struct F
{
B b [[gnu::packed]];
A a;
};
static_assert((sizeof(A) == 4) && (alignof(A) == 4));
static_assert((sizeof(B) == 8) && (alignof(B) == 8));
static_assert((sizeof(C) == 16) && (alignof(C) == 8));
static_assert((sizeof(D) == 16) && (alignof(D) == 8));
static_assert((sizeof(E) == 12) && (alignof(E) == 4));
static_assert((sizeof(F) == 12) && (alignof(F) == 4));
-- >8 --
Invocation: cat test.cpp | x86_64-linux-gnu-g++ -xc++ -std=c++17 -Wpacked -c -o
/dev/null -
Observed behavior:
:21:7: warning: packed attribute is unnecessary for ‘D::a’
[-Wattributes]
:33:7: warning: packed attribute is unnecessary for ‘F::b’
[-Wattributes]
Expected behaviur:
While the warning referring to line 21 is correct, the warning referring to
line 33 isn't, and thus no message is expected.
Please note that this report describes the same behavior as report #59220, but
is more generally applicable, as the aforementioned report uses an explicitly
overaligned type, and might thus give the false impression that overalignment
is a required prerequisite for the issue to.
[Bug c++/105125] Bogus and Misleading Warning: Packed attribute is unnecessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105125 Kimon.Hoffmann at lawo dot com changed: What|Removed |Added Known to fail||10.1.0, 11.1.0, 11.2.0, ||5.1.0, 6.1.0, 7.1.0, 8.1.0, ||9.1.0 --- Comment #1 from Kimon.Hoffmann at lawo dot com --- I checked the behavior with each major version since version 5, using the x.1.0 version as the representative, and can confirm that the issue is present in all versions checked.
[Bug regression/105126] New: Optimization regression gcc inserts not needed movsx when using switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126
Bug ID: 105126
Summary: Optimization regression gcc inserts not needed movsx
when using switch statement
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.schackier at gmail dot com
Target Milestone: ---
Given the following source code:
```cpp
bool is_bin_0(const char c) { return (c == '0' || c == '1'); }
bool is_bin_1(const char c) {
switch (c) {
case '0':
case '1':
return true;
default:
return false;
}
}
```
compiling with `-O3` gives the following output:
```asm
is_bin_0(char):
sub edi, 48
cmp dil, 1
setbe al
ret
is_bin_1(char):
movsx edi, dil
sub edi, 48
cmp edi, 1
setbe al
ret
```
The version using a switch generates an extra movsx instruction which, as far
is I understand the x86 CPU registers is not needed since DIL is the lower 8
bits of EDI anyways, but correct me if I'm wrong there.
This also seems to be a regression introduced with GCC-8.1 since GCC-4.5 to
GCC-7.5 generate the same assembly as for the first and second function and all
version after that including trunk produce different outputs.
[link to godbolt](https://godbolt.org/z/r3vhYbK6o)
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #24 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:86d8e0c0652ef5236a460b75c25e4f7093cc0651 commit r12-7960-g86d8e0c0652ef5236a460b75c25e4f7093cc0651 Author: Jason Merrill Date: Fri Apr 1 09:01:30 2022 -0400 Revert "c++: delayed parse DMI [PR96645]" The breakage from r12-7804 (in WebKit, particularly) is more of a can of worms than I think we can address in GCC 12, so let's return to the GCC 11 status quo for now and try again in stage 1. I think the change was correct for the current standard, but the standard needs a fix in this area; this is CWG issue 2335. PR c++/96645 This reverts commits r12-7804 and r12-7929.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jason Merrill changed: What|Removed |Added Target Milestone|12.0|13.0 Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #25 from Jason Merrill --- Reopening.
[Bug lto/105121] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105121 --- Comment #4 from Martin Liška --- Note that we don't bump LTO bytecode version during the development of a GCC release (stage1-4). Once we do a release, we keep eye on it.
[Bug c++/96645] [9/10/11/12 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #26 from Jason Merrill --- Created attachment 52734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52734&action=edit patch for tentative early DMI parsing This patch series (for GCC 13) adds a mode that tries to parse nested class DMI at the end of the nested class rather than at the end of all enclosing classes. If that fails, we try again at the later point. The first patch in the series extends our existing name-clash checking to cover nested classes as well, to catch the case where this can change name lookup results.
[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Target Milestone|--- |9.5 Priority|P3 |P2 Summary|wrong code with -m32|[9/10/11/12 Regression] |-mtune=i686 and |wrong code with -m32 |__builtin_shuffle() |-mtune=i686 and ||__builtin_shuffle() --- Comment #3 from Jakub Jelinek --- Started with r0-127375-gdd908cc5d8ee9e775c45b5a7078e1276f321d134
[Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:5f587c81bc558942d2988f5e2965a72471f5c202 commit r11-9754-g5f587c81bc558942d2988f5e2965a72471f5c202 Author: Vladimir N. Makarov Date: Fri Apr 1 09:48:57 2022 -0400 [PR105032] LRA: modify loop condition to find reload insns for hard reg splitting When trying to split hard reg live range to assign hard reg to a reload pseudo, LRA searches for reload insns of the reload pseudo assuming a specific order of the reload insns. This order is violated if reload involved in inheritance transformation. In such case, the loop used for reload insn searching can become infinite. The patch fixes this. gcc/ChangeLog: PR middle-end/105032 * lra-assigns.c (find_reload_regno_insns): Modify loop condition. gcc/testsuite/ChangeLog: PR middle-end/105032 * gcc.target/i386/pr105032.c: New.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #36 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:0d4b97f1ee5213dffce107bc9f260a22fb23b4b1 commit r12-7961-g0d4b97f1ee5213dffce107bc9f260a22fb23b4b1 Author: Xi Ruoyao Date: Wed Mar 30 22:22:45 2022 +0800 mips: Emit psabi diagnostic for return values affected by C++ zero-width bit-field ABI change [PR 102024] gcc/ PR target/102024 * config/mips/mips.cc (mips_fpr_return_fields): Detect C++ zero-width bit-fields and set up an indicator. (mips_return_in_msb): Adapt for mips_fpr_return_fields change. (mips_function_value_1): Diagnose when the presense of a C++ zero-width bit-field changes function returning in GCC 12. gcc/testsuite/ PR target/102024 * g++.target/mips/mips.exp: New test supporting file. * g++.target/mips/pr102024.C: New test.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #37 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:413187b0b3c87253838e4afbf8463b288b59 commit r12-7962-g413187b0b3c87253838e4afbf8463b288b59 Author: Xi Ruoyao Date: Thu Mar 31 23:40:23 2022 +0800 mips: Ignore zero width fields in arguments and issue -Wpsabi warning about C zero-width field ABI changes [PR102024] gcc/ PR target/102024 * config/mips/mips.cc (mips_function_arg): Ignore zero-width fields, and inform if it causes a psABI change. gcc/testsuite/ PR target/102024 * gcc.target/mips/pr102024-1.c: New test. * gcc.target/mips/pr102024-2.c: New test. * gcc.target/mips/pr102024-3.c: New test.
[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Cory Fields changed: What|Removed |Added CC||lists at coryfields dot com --- Comment #33 from Cory Fields --- Adding another +1. Still present in 10.3.0. Bitcoin Core's sha2 code uses avx2 when possible. We ran into this bug when bumping our toolchain: https://github.com/bitcoin/bitcoin/pull/24736 and opted to take Debian's patch: https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/blob/master/debian/patches/vmov-alignment.patch It's unfortunate that the best and most common advice for using avx2 with gcc/mingw is to use a patched compiler. Might it be possible to accept Debian's patch upstream?
[Bug target/105123] [9/10/11/12 Regression] wrong code with -m32 -mtune=i686 and __builtin_shuffle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105123
--- Comment #4 from Jakub Jelinek ---
Created attachment 52735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52735&action=edit
gcc12-pr105123.patch
Untested fix.
The problem was expansion of a (dead) statement
_1 = {u.0_3, u.0_3, u.0_3, u.0_3};
where the expansion overwrote the pseudo containing u.0_3:
(insn 10 9 11 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ashift:SI (reg:SI 83 [ u.0_3 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
(nil))
(insn 11 10 12 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ior:SI (reg:SI 83 [ u.0_3 ])
(reg:SI 83 [ u.0_3 ])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
(nil))
(insn 12 11 13 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ashift:SI (reg:SI 83 [ u.0_3 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
(nil))
(insn 13 12 14 (parallel [
(set (reg:SI 83 [ u.0_3 ])
(ior:SI (reg:SI 83 [ u.0_3 ])
(reg:SI 83 [ u.0_3 ])))
(clobber (reg:CC 17 flags))
]) "pr105123.c":6:31 -1
(nil))
(insn 14 13 15 (clobber (reg:V4HI 110)) "pr105123.c":6:31 -1
(nil))
(insn 15 14 16 (set (subreg:SI (reg:V4HI 110) 0)
(reg:SI 83 [ u.0_3 ])) "pr105123.c":6:31 -1
(nil))
(insn 16 15 17 (set (subreg:SI (reg:V4HI 110) 4)
(reg:SI 83 [ u.0_3 ])) "pr105123.c":6:31 -1
(nil))
[Bug c++/105127] New: Search Path not working on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105127 Bug ID: 105127 Summary: Search Path not working on Cygwin Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: samuel.d.darwin at gmail dot com Target Milestone: --- Hi, It appears that "Search Path" is not working as expected on the Cygwin platform. Your feedback would be appreciated. Notice on this page https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html it says: By default, the preprocessor looks for header files included by the quote form of the directive #include "file" first relative to the directory of the current file, and then in a preconfigured list of standard system directories. However, during testing, g++ fails to include a file in the same directory. An error such as this occurs: "fatal error: zutil.h: No such file or directory | #include "zutil.h" compilation terminated." How can it be replicated? The problem was discovered when running CI tests https://github.com/boostorg/boost-ci . Notice the .appveyor.yml file contained there. To run more Cygwin tests I forked that repository to https://github.com/samd2/boost-ci/tree/feature/searchpath and added Visual Studio 2019 and Visual Studio 2022 images. Appveyor's Visual Studio 2017 image was ok. The problem appears on 2019 and 2022. CI output at https://ci.appveyor.com/project/sam-original/boost-ci/builds/43100905 > Which version of gcc? # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0/configure --srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.2.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --disable-bootstrap --enable-languages=c,c++,fortran,lto,objc,obj-c++,jit --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (GCC) b2 --abbreviate-paths libs/boost-ci/test toolset=gcc cxxstd=11,14,1z address-model=64 link=shared,static variant=release -j3 > What command failed? Actually, g++ was called by another tools, b2 : b2 --abbreviate-paths libs/boost-ci/test toolset=gcc cxxstd=11,14,1z address-model=64 link=shared,static variant=release -j3 By adding the -d2 debugging flag to b2 it can be seen that the g++ command was: g++ -std=c++14 -fvisibility-inlines-hidden -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2\libs\boost-ci\test\gcc-11\rls\cxstd-14-iso\trgt-os-cygwn\thrd-mlt\vsblt-hdn\test.o" "libs\boost-ci\test\test.cpp" > What was the C++ source file contents? In this case the file test.cpp. It can be seen here: https://github.com/boostorg/boost-ci/blob/master/test/test.cpp It has the line "#include "test2.hpp" > What was the exact error? libs\boost-ci\test\test.cpp:18:10: fatal error: test2.hpp: No such file or directory 18 | #include "test2.hpp" | ^ View the entire build here: https://ci.appveyor.com/project/sam-original/boost-ci/builds/43100905 Let me know if you need more info. Thanks.
[Bug libstdc++/105128] New: source_location compile error for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128
Bug ID: 105128
Summary: source_location compile error for clang
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
It looks like clang just added source_location implementation but the built-in
looks different. Unfortunately, libcxx does not implement this either at this
point. However, the testsuite probably tells how clang implements this.
https://github.com/llvm/llvm-project/blob/d61487490022aaacc34249475fac3e208c7d767e/clang/test/CodeGenCXX/builtin-source-location.cpp
#include
int main()
{
std::source_location::current();
}
clang++ -o sourcelocation sourcelocation.cc -Ofast -std=c++2b -s -flto=thin
-fuse-ld=lld
In file included from sourcelocation.cc:1:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:46:41:
error: 'std::source_location::__impl' was not found; it must be defined before
'__builtin_source_location' is called
using __builtin_ret_type = decltype(__builtin_source_location());
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:13:
error: unknown type name '__builtin_ret_type'
current(__builtin_ret_type __p = __builtin_source_location()) noexcept
^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:32:
error: cannot initialize a parameter of type 'int' with an rvalue of type
'const std::source_location::__impl *'
current(__builtin_ret_type __p = __builtin_source_location()) noexcept
^ ~~~
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/12.0.1/../../../../include/c++/12.0.1/source_location:52:32:
note: passing argument to parameter '__p' here
3 errors generated.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #34 from Eric Botcazou --- > It's unfortunate that the best and most common advice for using avx2 with > gcc/mingw is to use a patched compiler. Might it be possible to accept > Debian's patch upstream? Sure, but they need to submit it first, we cannot do it for them.
[Bug regression/105126] Optimization regression gcc inserts not needed movsx when using switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-04-01 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with my r8-2897-g02e637d86f9ecb6d, will take a look.
[Bug libstdc++/105128] source_location compile error for latest clang 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128 --- Comment #1 from cqwrteur --- Created attachment 52736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52736&action=edit Modified source_location header that works on both gcc and clang It looks like clang requires __impl to be defined before __builtin_source_location() call. Just change the location for where it should be defined and it works. Can we fix it?
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Stephen Kitt changed:
What|Removed |Added
CC||steve at sk2 dot org
--- Comment #35 from Stephen Kitt ---
Created attachment 52737
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52737&action=edit
Use unaligned VMOV instructions (for Windows targets)
The reason I didn't submit the Debian patch is that it unconditionally replaces
V...{U,A} with V...U instructions. That's fine when we know the target needs
something like that, which is the case when we're building a Windows
cross-compiler; but I don't think it's suitable for general use as-is. It would
need a build-time conditional at the very least.
Anyway, I'll add it as an attachment here; I'll try to find time to make it
generally applicable. I haven't filed copyright assignment paperwork for me
personally; if the patch needs it, consider it submitted by sk...@redhat.com
under the corporate copyright assignment agreement.
[Bug libstdc++/105128] source_location compile error for latest clang 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52738&action=edit gcc12-pr105128.patch So like this untested patch? Can test it with gcc, but don't have a new enough clang around.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #36 from Jakub Jelinek --- That patch is certainly unacceptable, not only because it affects non-Windows too, but even on Windows it will unnecessarily pessimize e.g. accesses to data sections or heap that can be aligned. If the Windows ABI doesn't align stack or not as much as gcc assumes, then a fix would ensure only automatic vars on Windows are accessed always using unaligned vector instructions provided dynamic stack realignment is not an option.
[Bug libstdc++/105128] source_location compile error for latest clang 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128 --- Comment #3 from cqwrteur --- (In reply to Jakub Jelinek from comment #2) > Created attachment 52738 [details] > gcc12-pr105128.patch > > So like this untested patch? > Can test it with gcc, but don't have a new enough clang around. yes, it should work on clang.
[Bug rtl-optimization/104771] '-fcompare-debug' failure w/ -mno-vsx -O1 -frename-registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104771 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner --- I am unable to recreate this, but I'm guessing it is the same bug as PR105041.
[Bug tree-optimization/105129] New: missing -Wformat-overflow for %b and %B directives in C2X standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105129 Bug ID: 105129 Summary: missing -Wformat-overflow for %b and %B directives in C2X standard Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: frolov.da at phystech dot edu Target Milestone: ---
[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105110 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:95533fe4f014c10dd18de649927668aba6117daf commit r12-7966-g95533fe4f014c10dd18de649927668aba6117daf Author: Patrick Palka Date: Fri Apr 1 14:56:20 2022 -0400 c++: deducing from class type of NTTP [PR105110] Here when attempting to deduce T in the NTTP type A from the argument type 'const A', we give up due to the const: types âAâ and âconst Aâ have incompatible cv-qualifiers But since the type of an NTTP cannot be cv-qualified, it seems natural to ignore cv-qualifiers on the argument type before attempting to unify the two types. PR c++/105110 gcc/cp/ChangeLog: * pt.cc (unify) : Drop cv-quals from the argument type of an NTTP before deducing from it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-class52.C: New test.
[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105110 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 12, thanks for the bug report.
[Bug c++/105110] NTTP type deduction fails when dependent of previous NTTPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105110 --- Comment #4 from Jakub Gałecki --- Awesome! Happy to be of use.
[Bug c++/101677] [11/12 Regression] Concept with use of incomplete type succeeds on GCC 10.3.0, fails on GCC 11 onward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/103852] [10/11/12 Regression] Alias template argument deduction is available in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103852 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org
[Bug c++/105130] New: gcc does not warn about unused return value of last expression of statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130
Bug ID: 105130
Summary: gcc does not warn about unused return value of last
expression of statement expr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dani at danielbertalan dot dev
Target Milestone: ---
Created attachment 52739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52739&action=edit
Proposed patch
The following code does not cause a warning about the return value of the foo()
function being ignored:
$ cat unused.cc
[[nodiscard]] int foo();
int main() {
({ foo(); });
}
$ g++ -Wunused-value -std=c++20 unused.cc
[no warnings]
The issue seems to be that CLEANUP_POINT_EXPR and STATEMENT_LIST -- which are
what statement expressions are turned into -- are not handled in
convert_to_void() (cp/cvt.cc).
The attached patch resolves the issue, but as a newbie to hacking on gcc, I
can't evaluate if it has any unintended consequences.
[Bug c/105131] New: Warning for mismatched declaration/definition with enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131
Bug ID: 105131
Summary: Warning for mismatched declaration/definition with
enum
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
For a testcase such as
enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void) { return z; }
If the implementation type of 'enum E' is not 'int',
we will correctly emit an error (e.g. -fshort-enums).
It would be desirable to emit a warning in this case,
because it is probably a mistake and definitely a
portability error.
[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105130 --- Comment #1 from Daniel Bertalan --- Created attachment 52740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52740&action=edit Proposed patch #2 Actually, my proposed patch was definitely incorrect. It didn't allow me to circumvent the warning by explicitly casting to void. This new version fixes that issue.
[Bug c/105131] Warning for mismatched declaration/definition with enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-04-01 Ever confirmed|0 |1 Keywords||diagnostic CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #37 from Eric Botcazou --- > If the Windows ABI doesn't align stack or not as much as gcc assumes, then a > fix would ensure only automatic vars on Windows are accessed always using > unaligned vector instructions provided dynamic stack realignment is not an > option. It's classical double-word alignment, i.e. 16 bytes, and AVX requires 32 bytes. The implementation of dynamic stack realignment is too much of a kludge to be safely used on Windows IMO so, yes, the way out is probably unaligned vector instructions.
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #38 from R Copley --- (A patch to emit unaligned instructions should probably resolve bug 49001 instead of this one, 54412.) Could dynamic alignment be achieved, not for automatic variables and function parameters, but for registers spilled to the stack (due to register exhaustion, or because they may be clobbered)? So that users can write code that stores over-aligned objects on the heap only. If SEH is the problem, can alignment be accounted for in cases where SEH is not in use (if there are any such cases)? I'm thinking of -fno-exceptions, and dwarf (on x86) or setjump/longjump exceptions. Sorry if those are stupid questions.
[Bug tree-optimization/105132] New: ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132
Bug ID: 105132
Summary: ICE in in operator[], at vec.h:889 with
-march=skylake-avx512 -O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/xedcfP338
Reproducer:
short a;
extern int b[];
int c;
void d(long f[][5][5][17], int g[][5][5][17]) {
for (short e = 0; e < 17; e++) {
a = g[19][2][3][e];
b[e] = c & (f[3][2][3][e] && g[19][2][3][e]);
}
}
Error:
>$ g++ -march=skylake-avx512 -c -O3 func.cpp
during GIMPLE pass: slp
func.cpp: In function 'void d(long int (*)[5][5][17], int (*)[5][5][17])':
func.cpp:4:6: internal compiler error: in operator[], at vec.h:889
4 | void d(long f[][5][5][17], int g[][5][5][17]) {
| ^
0x99508e vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:889
0x996d5b vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:6108
0x996d5b vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:1495
0x996d5b vectorizable_operation
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:6375
0x2123ab8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.cc:11245
0x14c4fc7 vect_schedule_slp_node
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7320
0x14d6346 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7515
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d60d9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7496
0x14d699f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:7632
0x14d8163 vect_slp_region
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:5994
0x14d9113 vect_slp_bbs
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:6106
0x14d950c vect_slp_function(function*)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.cc:6194
0x14e13e2 execute
/testing/gcc/gcc_src_master/gcc/tree-vectorizer.cc:1506
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
GCC version:
gcc version 12.0.1 20220401 (git://gcc.gnu.org/git/gcc.git:master
15d683d4f0b390b27c54a7c92c6e4f33195bdc93) (GCC)
[Bug c/105131] Warning for mismatched declaration/definition with enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105131
--- Comment #2 from Marek Polacek ---
Maybe something like the attached patch would work (but needs a new option,
maybe -Wenum-int-mismatch, possibly enabled by -Wall?). With it, the following
test
enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void) { return z; }
void bar(int);
void bar(enum E);
extern enum E arr[10];
extern int arr[10];
is diagnosed like this:
105131.c:3:8: warning: conflicting types for ‘foo’ due to enum/integer
mismatch; have ‘enum E(void)’
3 | enum E foo(void) { return z; }
|^~~
105131.c:2:5: note: previous declaration of ‘foo’ with type ‘int(void)’
2 | int foo(void);
| ^~~
105131.c:6:6: warning: conflicting types for ‘bar’ due to enum/integer
mismatch; have ‘void(enum E)’
6 | void bar(enum E);
| ^~~
105131.c:5:6: note: previous declaration of ‘bar’ with type ‘void(int)’
5 | void bar(int);
| ^~~
105131.c:9:12: warning: conflicting types for ‘arr’ due to enum/integer
mismatch; have ‘int[10]’
9 | extern int arr[10];
|^~~
105131.c:8:15: note: previous declaration of ‘arr’ with type ‘enum E[10]’
8 | extern enum E arr[10];
| ^~~
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index c701f07befe..60a0bb3ea36 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -1995,9 +1995,12 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
bool pedwarned = false;
bool warned = false;
+ bool enum_and_int_p = false;
auto_diagnostic_group d;
- if (!comptypes (oldtype, newtype))
+ int comptypes_result = comptypes_check_enum_int (oldtype, newtype,
+ &enum_and_int_p);
+ if (!comptypes_result)
{
if (TREE_CODE (olddecl) == FUNCTION_DECL
&& fndecl_built_in_p (olddecl, BUILT_IN_NORMAL)
@@ -2139,6 +2142,14 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
return false;
}
}
+ else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL)
+{
+ location_t newloc = DECL_SOURCE_LOCATION (newdecl);
+ auto_diagnostic_group d;
+ warned = warning_at (newloc, 0, "conflicting types for %q+D due to "
+ "enum/integer mismatch; have %qT", newdecl,
+ newtype);
+}
/* Redeclaration of a type is a constraint violation (6.7.2.3p1),
but silently ignore the redeclaration if either is in a system
@@ -2148,7 +2159,6 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
if (TREE_CODE (newdecl) == TYPE_DECL)
{
bool types_different = false;
- int comptypes_result;
comptypes_result
= comptypes_check_different_types (oldtype, newtype, &types_different);
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index c70f0ba5ab6..2bcb9662620 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -685,6 +685,7 @@ extern tree require_complete_type (location_t, tree);
extern bool same_translation_unit_p (const_tree, const_tree);
extern int comptypes (tree, tree);
extern int comptypes_check_different_types (tree, tree, bool *);
+extern int comptypes_check_enum_int (tree, tree, bool *);
extern bool c_vla_type_p (const_tree);
extern bool c_mark_addressable (tree, bool = false);
extern void c_incomplete_type_error (location_t, const_tree, const_tree);
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 6c4af5e4cde..b6a45fd9836 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1055,7 +1055,7 @@ comptypes (tree type1, tree type2)
/* Like comptypes, but if it returns non-zero because enum and int are
compatible, it sets *ENUM_AND_INT_P to true. */
-static int
+int
comptypes_check_enum_int (tree type1, tree type2, bool *enum_and_int_p)
{
const struct tagged_tu_seen_cache * tagged_tu_seen_base1 =
tagged_tu_seen_base;
[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 --- Comment #39 from Eric Botcazou --- > If SEH is the problem, can alignment be accounted for in cases where SEH is > not in use (if there are any such cases)? I'm thinking of -fno-exceptions, > and dwarf (on x86) or setjump/longjump exceptions. The hitch is that Setjmp/Longjmp is implemented on top of SEH on 64-bit Windows, which means that SEH information must always be generated, even in plain C.
[Bug c++/101894] [11/12 Regression] ICE with multiple friend declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101894 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 --- Comment #2 from David Malcolm --- make pdf is looking for the images in: gcc/jit/docs/_build/texinfo/libgccjit-figures but they're in the source tree in: gcc/jit/docs/_build/texinfo I just tried: git mv gcc/jit/docs/_build/texinfo/*.png gcc/jit/docs/_build/texinfo/libgccjit-figures and it seems to fix the "make pdf" for me. Will test a bit more.
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #38 from Segher Boessenkool ---
+ cat test.c
struct foo
{
int : 0;
double a;
int : 0;
double b;
int : 0;
};
extern void func(struct foo);
void
pass_foo(void)
{
struct foo test;
test.a = 114;
test.b = 514;
func(test);
}
+ cc -version
MIPSpro Compilers: Version 7.30
+ cc -64 -ansi -c test.c -o test.o
Cannot find license file (-1,73:2) No such file or directory
This product (cc) requires a license password.
For license installation and trouble shooting
information visit the web page:
http://www.sgi.com/Support/Licensing/install_docs.html
To obtain a Permanent license (proof of purchase
required) or an Evaluation license please
visit our license request web page:
http://www.sgi.com/Products/license.html
or send a blank email message to:
lice...@sgi.com
In North America, Silicon Graphics' customers may request
Permanent licenses by sending a facsimile to:
(650) 390-0537
or by calling our technical support hotline
1-800-800-4SGI
If you are Outside of North America or you are not a Silicon
Graphics support customer then contact your local support provider.
qemu: Unsupported syscall: sgisys(107)
qemu: Unsupported syscall: sgisys(111)
qemu: Unsupported syscall: sgisys(107)
qemu: Unsupported syscall: sgisys(111)
### Assertion failure at line 137 of ../../be/cg/MIPS/exp_loadstore.cxx:
### Compiler Error in file test.c during Code_Expansion phase:
### unexpected mtypes in Pick_Load_Instruction
cc INTERNAL ERROR: /usr/lib32/cmplrs/be returned non-zero status 1
[Bug fortran/65347] [F03] Final subroutine not called for function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347 Damian Rouson changed: What|Removed |Added CC||damian at archaeologic dot codes --- Comment #3 from Damian Rouson --- I suspect the code below is a simpler reproducer (25 lines) of this bug % cat missing-finalization.f90 module object_m implicit none type object_t contains final :: count_finalizations end type contains subroutine count_finalizations(self) type(object_t) self print *,"finalization" end subroutine function new_object() type(object_t) new_object end function end module use object_m implicit none type(object_t) object object = new_object() end % gfortran missing-finalization.f90 % ./a.out % gfortran --version GNU Fortran (Homebrew GCC 11.2.0_3) 11.2.0
[Bug lto/105133] New: lto/gold: lto failed to link --start-lib/--end-lib in gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105133
Bug ID: 105133
Summary: lto/gold: lto failed to link --start-lib/--end-lib in
gold
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: luoxhu at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi, linker gold supports --start-lib and --end-lib to "mimics the
semantics of static libraries, but without needing to actually create
the archive file."(https://reviews.llvm.org/D66848). Sometimes large
application may introduce multiple libraries from different repositories with
same source code, they would be linked into one binary finally, recently I
suffered from a link error with gold as linker and reduced an example as below:
cat hello.c
extern int hello(int a);
int main(void)
{
return 0; /* hello(10); */
}
cat ./B/libhello.c
#include
int hello(int a)
{
puts("Hello");
return 0;
}
cat ./C/libhello.c
#include
int hello(int a)
{
puts("Hello");
return 0;
}
(1) NON lto link with gold is OK:
gcc -O2 -o ./B/libhello.c.o -c ./B/libhello.c
gcc-ar qc ./B/libhello.a ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -o ./C/libhello.c.o -c ./C/libhello.c
gcc-ar qc ./C/libhello.a ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -fuse-ld=gold
(2) lto link with gold fails with redefinition:
gcc -O2 -flto -o ./B/libhello.c.o -c ./B/libhello.c
gcc-ar qc ./B/libhello.a ./B/libhello.c.o
gcc-ranlib ./B/libhello.a
gcc -O2 -flto -o ./C/libhello.c.o -c ./C/libhello.c
gcc-ar qc ./C/libhello.a ./C/libhello.c.o
gcc-ranlib ./C/libhello.a
gcc hello.c -o hello.o -c -O2 -flto
gcc -o hellow hello.o -Wl,--start-lib ./B/libhello.c.o -Wl,--end-lib
-Wl,--start-lib ./C/libhello.c.o -Wl,--end-lib -O2 -flto -fuse-ld=gold
./B/libhello.c:5:5: error: 'hello' has already been defined
5 | int hello(int a)
| ^
./B/libhello.c:5:5: note: previously defined here
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld.gold: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
This error happens at function gcc/lto/lto-symtab.c:lto_symtab_resolve_symbols,
simply remove the error_at line could work, but this may be not a reasonable
fix.
/* Find the single non-replaceable prevailing symbol and
diagnose ODR violations. */
for (e = first; e; e = e->next_sharing_asm_name)
{
if (!lto_symtab_resolve_can_prevail_p (e))
continue;
/* If we have a non-replaceable definition it prevails. */
if (!lto_symtab_resolve_replaceable_p (e))
{
if (prevailing)
{
error_at (DECL_SOURCE_LOCATION (e->decl),
"%qD has already been defined", e->decl);
inform (DECL_SOURCE_LOCATION (prevailing->decl),
"previously defined here");
}
prevailing = e;
}
}
cat hellow.res
3
hello.o 2
192 ccb9165e03755470 PREVAILING_DEF main
197 ccb9165e03755470 PREVAILING_DEF_IRONLY s
./B/libhello.c.o 1
205 68e0b97e93a52d7a PREEMPTED_REG hello
./C/libhello.c.o 1
205 18fe2d3482bfb511 PREEMPTED_REG hello
Secondly, If call hello(10) in hello.c , there will be NO error reported out.
The difference is the resolution type is changed from PREEMPTED_REG to
RESOLVED_IR/PREVAILING_DEF_IRONLY.
3
hello.o 3
192 19ef867d12f62129 PREVAILING_DEF main
197 19ef867d12f62129 PREVAILING_DEF_IRONLY s
201 19ef867d12f62129 RESOLVED_IR hello
./B/libhello.c.o 1
205 23c5c855935478ce PREVAILING_DEF_IRONLY hello
./C/libhello.c.o 1
205 abbf050f5c23b448 PREEMPTED_REG hello
Is this a valid bug? Thanks.
[Bug c/105134] New: tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
Bug ID: 105134
Summary: tree-vectorize produces error code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: piliu at redhat dot com
Target Milestone: ---
On x86_64, kexec-tools built with gcc-12 can not boot the 2nd kernel
successfully.
After debugging, it turns out to be related with "tree-vectorize" option.
As kexec-tools commit 1b03cf7 purgatory: do not enable vectorization
automatically for purgatory compiling.
I have no idea about what happens, but it seems to be related with the
generation of the code piece
void sha256_starts( sha256_context *ctx )
{
ctx->total[0] = 0;
ctx->total[1] = 0;
ctx->state[0] = 0x6A09E667;
ctx->state[1] = 0xBB67AE85;
ctx->state[2] = 0x3C6EF372;
ctx->state[3] = 0xA54FF53A;
ctx->state[4] = 0x510E527F;
ctx->state[5] = 0x9B05688C;
ctx->state[6] = 0x1F83D9AB;
ctx->state[7] = 0x5BE0CD19;
}
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #1 from piliu at redhat dot com ---
More description about the background.
There is a built file kexec-tools/purgatory/purgatory.ro, which is a tiny
bootload, compare and verify the sha256, if ok, then jump to the 2nd kernel.
The original sha256 value comes from
update_purgatory()
{
..
elf_rel_set_symbol(&info->rhdr, "sha256_regions", ®ion,
sizeof(region));
elf_rel_set_symbol(&info->rhdr, "sha256_digest", &digest,
sizeof(digest));
}
They are based on the loaded linux kernel image.
Now, "kexec -e" and purgatory.ro runs, and in
void purgatory(void)
{
printf("I'm in purgatory\n");
setup_arch();
if (!skip_checks && verify_sha256_digest()) {
for(;;) {
/* loop forever */ --> stuck here
}
}
post_verification_setup_arch();
}
[Bug c/105134] tree-vectorize produces error code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
--- Comment #2 from piliu at redhat dot com ---
More specific, the following directive beats out the bug.
diff --git a/util_lib/sha256.c b/util_lib/sha256.c
index 2e61a31..3b3e533 100644
--- a/util_lib/sha256.c
+++ b/util_lib/sha256.c
@@ -38,6 +38,7 @@
(b)[(i) + 3] = (uint8_t) ( (n) ); \
}
+ __attribute__((optimize("no-tree-vectorize")))
void sha256_starts( sha256_context *ctx )
