[Bug c++/38542] placement new and name lookup in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38542 --- Comment #2 from Andrew Pinski --- clang and even ICC accept this code now.
[Bug target/97448] Unneccessary stack frame when using stack protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97448
Andrew Pinski changed:
What|Removed |Added
Target|powerpc |powerpc-*-*linux (32bit)
--- Comment #1 from Andrew Pinski ---
Reduced testcase -O2 -fstack-protector:
int fls64(int x)
{
return x;
}
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Andrew Pinski --- Fixed: https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353733.html I forgot to include the PR # in the changelog part.
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28351 --- Comment #7 from Andrew Pinski --- Filed the binutils issue: https://sourceware.org/bugzilla/show_bug.cgi?id=28351
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Andrew Pinski changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #6 from Andrew Pinski --- This is more complex than I originally thought. first off s_aarch64_elf_cons in gas/config/tc-aarch64.c needs relocation syntax support: /* N.B. the support for relocation suffix in this directive needs to be implemented properly. */ Second is :DTPREL: relocation needs to be added. I will be filing the binutils bug for this soon.
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- output_dwarf_dtprel (TARGET_ASM_OUTPUT_DWARF_DTPREL) is not defined for aarch64. Mine, I am going to try and test the obvious patch.
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344
--- Comment #4 from Andrew Pinski ---
if (GET_CODE (rtl) == SYMBOL_REF
&& SYMBOL_REF_TLS_MODEL (rtl) != TLS_MODEL_NONE)
{
dw_loc_descr_ref temp;
/* If this is not defined, we have no way to emit the data. */
if (!targetm.have_tls || !targetm.asm_out.output_dwarf_dtprel)
break;
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug sanitizer/102144] hwsan has a hardcoded pagesize requirement for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102144 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://github.com/google/s ||anitizers/issues/1446 --- Comment #2 from Andrew Pinski --- Submitted upstream: https://github.com/google/sanitizers/issues/1446
[Bug sanitizer/102144] hwsan has a hardcoded pagesize requirement for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102144
--- Comment #1 from Andrew Pinski ---
This fixes the problem for me:
diff --git a/libsanitizer/hwasan/hwasan_thread_list.h
b/libsanitizer/hwasan/hwasan_thread_list.h
index 15916a802d6..c13c5910b95 100644
--- a/libsanitizer/hwasan/hwasan_thread_list.h
+++ b/libsanitizer/hwasan/hwasan_thread_list.h
@@ -57,7 +57,7 @@ static uptr RingBufferSize() {
// FIXME: increase the limit to 8 once this bug is fixed:
// https://bugs.llvm.org/show_bug.cgi?id=39030
for (int shift = 1; shift < 7; ++shift) {
-uptr size = 4096 * (1ULL << shift);
+uptr size = (64*4096) * (1ULL << shift);
if (size >= desired_bytes)
return size;
}
Let me submit a bug upstream.
[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774 Bug 84774 depends on bug 102386, which changed state. Bug 102386 Summary: [12 regression] bogus -Wrestrict for unreachable memcpy() https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102386 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/102386] [12 regression] bogus -Wrestrict for unreachable memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102386
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
CC||msebor at gcc dot gnu.org
Keywords||diagnostic
Blocks||84774
--- Comment #1 from Martin Sebor ---
The warning is correct (at -O0 GCC issues a -Wuninitialized for dereferencing
the uninitialized pBlb), but I suspect you're expecting it to be suppressed
because the memcpy call is eliminated. I've simplified the test case and
changed the names in it to make it easier to see what I assume you're really
pointing out:
$ cat pr102386.c && gcc -O2 -S -Wall pr102386.c
struct S { int n, a[8]; };
static int n = 0; // not const but not modified
void f (struct S *p)
{
if (n)// folded to false by ccp2
{
void *q = p->a, *r = p->a;
int n = 8;
__builtin_memcpy (q, r, n); // -Wrestrict
}
}
pr102386.c: In function ‘f’:
pr102386.c:11:7: warning: ‘__builtin_memcpy’ accessing 8 bytes at offsets 4 and
4 overlaps 8 bytes at offset 4 [-Wrestrict]
11 | __builtin_memcpy (q, r, n);
| ^~
Although the memcpy call does ultimately end up removed (by ccp2) as
unreachable because the static global variable N is never set in the file, the
warning is issued before that happens, during folding. This might change
if/when warnings are deferred until the end of compilation but I don't see this
use case as compelling enough to consider this particular instance a bug. Feel
free to reopen it if you have a more compelling use case.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict
[Bug c/98379] Unknown tree: c_maybe_const_expr in a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98379 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-18 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/98303] cmov seems not to swap condition during RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98303 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement Summary|[x86] Bad register |cmov seems not to swap |allocation when reproducing |condition during RA |assembly code | Last reconfirmed||2021-09-18 --- Comment #1 from Andrew Pinski --- This is the case where register allocator and cmov's (and 2 operands) don't get along.
[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401 --- Comment #4 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #3) > There are things that need to be clarified, in particular value > initialization should clear even the padding bits, so supposedly > std::bit_cast of Item() if the NSDMIs would be dropped might be well defined > and ok in constexpr contexts (we don't implement that currently, and don't > implement it even at runtime, we treat padding bits as always undefined), I think that's a bug. > but the above testcase has a user defined constructor and therefore no zero No it doesn't. It has no constructor that is user-declared, so a default constructor is implicitly defined as defaulted. That default constructor is non-trivial (because of the default member-initializers) but it's still implicitly defined. List-initialization with an empty init list means value-initialization. Since there is no user-provided default constructor, that means: "the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;" So it should be zero-initialized (which zeroes all padding) and then it should be default-initialized (which uses the implicitly-defined default constructor, which uses the NSDMIs). So the padding bits should be initialized, no?
[Bug tree-optimization/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102404 --- Comment #1 from Freddie Witherden --- Created attachment 51481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51481=edit Generated assembly.
[Bug tree-optimization/102404] New: Loop vectorized with 32 byte vectors actually uses 16 byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102404 Bug ID: 102404 Summary: Loop vectorized with 32 byte vectors actually uses 16 byte vectors Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: freddie at witherden dot org Target Milestone: --- Created attachment 51480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51480=edit Test case Consider the loop on L11 of the attached file. Compiling as: ❯ gcc -march=tigerlake -Ofast -mprefer-vector-width=512 -S -fopenmp test.c -fopt-info test.c:25:37: optimized: loop vectorized using 32 byte vectors test.c:4:6: optimized: loop turned into non-loop; it never loops which notes that (as requested) the loop has been vectorized using 32-byte (zmm) vectors. Inspecting the resulting assembly (also attached) we observe that has actually ben unrolled by a factor of two and then vectorized using 16-byte (ymm) vectors. As a point of comparison recent versions of Clang use 32-byte vectors for this loop, resulting in code which is half the size.
[Bug c/98184] ICE in purge_dead_edges, at cfgrtl.c:3297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98184 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-18 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/48297] Suboptimal optimization of boolean expression addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment #3 from Gabriel Ravier --- We should... ? Also, the code generation seems to be slightly better now, though I don't think ideal yet, but I'm not sure.
[Bug middle-end/102403] [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-09-18 Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Blocks||24639 Target Milestone|--- |12.0 --- Comment #1 from Martin Sebor --- The ICE was observed on nios2-linux-gnu and csky-linux-gnu but the test case in comment 0 reproduces it with the native GCC on x86_64. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/102403] New: [12 Regression] ICE in in init_from_control_deps, at gimple-predicate-analysis.cc:2364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102403
Bug ID: 102403
Summary: [12 Regression] ICE in in init_from_control_deps, at
gimple-predicate-analysis.cc:2364
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As reported in
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579736.html, the
following test case reduced from s_fmaf.c triggers an ICE in the new
predicate-analysis module introduced in r12-3640.
$ cat s_fmaf.c && gcc -S -O2 -Wall -Werror s_fmaf.c
int __fmaf (void)
{
int a = 0;
int b, c, d, e, f;
int r = 0;
switch (b)
{
default:
c |= 1;
case 0:
if (c == 0)
a = 1;
switch (d) {
case 15:
f = c;
break;
case 11:
case 6:
case 4:
f = c;
case 10:
e = a;
}
if (e == 0)
f = 0;
r = f;
}
return r;
}
s_fmaf.c: In function ‘__fmaf’:
s_fmaf.c:8:3: error: ‘b’ is used uninitialized [-Werror=uninitialized]
8 | switch (b)
| ^~
s_fmaf.c:4:7: note: ‘b’ was declared here
4 | int b, c, d, e, f;
| ^
s_fmaf.c:4:13: error: ‘d’ is used uninitialized [-Werror=uninitialized]
4 | int b, c, d, e, f;
| ^
s_fmaf.c:4:10: error: ‘c’ may be used uninitialized
[-Werror=maybe-uninitialized]
4 | int b, c, d, e, f;
| ^
during GIMPLE pass: uninit
s_fmaf.c:1:5: internal compiler error: in init_from_control_deps, at
gimple-predicate-analysis.cc:2364
1 | int __fmaf (void)
| ^~
0x264d8b4 predicate::init_from_control_deps(vec
const*, unsigned int)
/src/gcc/master/gcc/gimple-predicate-analysis.cc:2364
0x264c28c predicate::init_from_phi_def(gphi*)
/src/gcc/master/gcc/gimple-predicate-analysis.cc:1829
0x264c47a predicate::is_use_guarded(gimple*, basic_block_def*, gphi*, unsigned
int, hash_set >*)
/src/gcc/master/gcc/gimple-predicate-analysis.cc:1902
0x264c5b3 predicate::is_use_guarded(gimple*, basic_block_def*, gphi*, unsigned
int)
/src/gcc/master/gcc/gimple-predicate-analysis.cc:1933
0x1672895 find_uninit_use
/src/gcc/master/gcc/tree-ssa-uninit.c:1092
0x1672b11 warn_uninitialized_phi
/src/gcc/master/gcc/tree-ssa-uninit.c:1149
0x1673090 execute_late_warn_uninitialized
/src/gcc/master/gcc/tree-ssa-uninit.c:1275
0x167310b execute
/src/gcc/master/gcc/tree-ssa-uninit.c:1288
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/56883] error openmp parallel for order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56883 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |4.8.1 --- Comment #6 from Andrew Pinski --- Fixed so closing.
[Bug bootstrap/102302] [12 Regression] ICE during RTL pass: expand: in gen_lowpart_general, at rtlhooks.c:57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102302 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401 --- Comment #3 from Jakub Jelinek --- There are things that need to be clarified, in particular value initialization should clear even the padding bits, so supposedly std::bit_cast of Item() if the NSDMIs would be dropped might be well defined and ok in constexpr contexts (we don't implement that currently, and don't implement it even at runtime, we treat padding bits as always undefined), but the above testcase has a user defined constructor and therefore no zero initialization happens, and even if it wouldn't, any copying around (both copy construction and assignments) will make those bits undefined as well.
[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Yes this is the way the C++ standard is defined. Even clang rejects it. I would have thought __builtin_clear_padding could be used in constexpr but I was wrong.
[Bug tree-optimization/102402] Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target |tree-optimization
Last reconfirmed||2021-09-18
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, note the best code is generated by:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
int t =0;
if (track->modT == 0)
t = 3;
else
t = 12;
track->flags |= t;
}
This is then a gimple level issue where:
if (_1 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_3 = pretmp_6 | 3;
goto ; [100.00%]
[local count: 536870913]:
_5 = pretmp_6 | 12;
[local count: 1073741824]:
# cstore_12 = PHI <_3(3), _5(4)>
is not transformed into:
if (track->modT == 0)
t = 3;
else
t = 12;
cstore_12 = pretmp_6 | t;
There is also a sinking issue though I don't know if has a wider effect (and
does not matter in this case really).
Take:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
int t =0;
int t2 = track->modT;
int t1 = track->flags;
if (t2 == 0)
t = 3;
else
t = 12;
track->flags = t1|t;
}
The load for track->flags is not sunk after the if.
[Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Bug ID: 102402
Summary: Seemingly suboptimal optimization of jmp/cmovcc for
conditionally loading constants
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
struct MusicPlayerTrack
{
uint8_t flags;
uint8_t modT;
};
void ClearModM(struct MusicPlayerTrack *track, uint8_t modT)
{
if (track->modT == 0)
track->flags |= 3;
else
track->flags |= 12;
}
This is optimized weirdly by GCC. Leaving it as-is gives this AMD64 assembly:
ClearModM:
movzx edx, BYTE PTR [rdi]
mov eax, edx
or eax, 12
cmp BYTE PTR [rdi+1], 0
jne .L3
mov eax, edx
or eax, 3
.L3:
mov BYTE PTR [rdi], al
ret
Whereas changing the `if` to `if (modT == 0)` gives this:
ClearModM:
movzx eax, BYTE PTR [rdi]
mov edx, eax
or eax, 12
or edx, 3
test sil, sil
cmove eax, edx
mov BYTE PTR [rdi], al
ret
It seems to me that this should be better than the first output, though of
course this could be the other way considering how finicky cmovcc seems to be,
but it seems to me like at least one should be preferred above the other.
Note that this also occurs on IA-32, so the issue seems unrelated to whether
modT is in a register or in memory. Perhaps it's about whether it's a function
argument ?
[Bug c++/102401] std::bit_cast falls over, seemingly due to some invisible alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why do you think GCC is not right? The Item class has 3 bytes of padding, and the Data class doesn't have any. So, when evaluated at runtime, it would be a UB, while during constant evaluation it has to be an error.
[Bug c++/102401] New: std::bit_cast falls over, seemingly due to some invisible alignment requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
Bug ID: 102401
Summary: std::bit_cast falls over, seemingly due to some
invisible alignment requirements
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: krax.powah at gmail dot com
Target Milestone: ---
GCC Version: The current truck (12.0.0 20210917), but also present on all
versions which support std::bit_cast.
Repro case (https://godbolt.org/z/zWbMnMfvx):
```
#include
struct Item
{
float a = 0;
float b = 0;
char c = 0; // Removing this or changing it to type with a size of 4
};// fixes it.
struct M
{
struct Data { char d[sizeof(Item)]; };
static constexpr Data build(Item item)
{
Data d {};
d = std::bit_cast(item);
return d;
}
};
int main(void)
{
constexpr auto data = M::build({}); // Only occurs if this is a
constexpr assignment
}
```
Result:
```
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20210917/include/c++/12.0.0/bit: In
function 'int main()':
:26:35: in 'constexpr' expansion of 'M::build(Item{(float)0,
(float)0, '\000'})'
:18:32: in 'constexpr' expansion of 'std::bit_cast(item)'
/opt/compiler-explorer/gcc-trunk-20210917/include/c++/12.0.0/bit:77:33:
error: '__builtin_bit_cast' accessing uninitialized byte at offset 9
77 | return __builtin_bit_cast(_To, __from);
| ^~~
ASM generation compiler returned: 1
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20210917/include/c++/12.0.0/bit: In
function 'int main()':
:26:35: in 'constexpr' expansion of 'M::build(Item{(float)0,
(float)0, '\000'})'
:18:32: in 'constexpr' expansion of 'std::bit_cast(item)'
/opt/compiler-explorer/gcc-trunk-20210917/include/c++/12.0.0/bit:77:33:
error: '__builtin_bit_cast' accessing uninitialized byte at offset 9
77 | return __builtin_bit_cast(_To, __from);
| ^~~
Execution build compiler returned: 1
```
[Bug tree-optimization/102393] Failure to optimize 2 8-bit stores into a single 16-bit store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102393
--- Comment #3 from Gabriel Ravier ---
It seems odd that the equivalent 32-bit pattern, i.e. this:
void HeaderWriteU32LE(int offset, uint32_t value, uint8_t *RomHeader)
{
RomHeader[offset] = value;
RomHeader[offset + 1] = value >> 8;
RomHeader[offset + 2] = value >> 16;
RomHeader[offset + 3] = value >> 24;
}
is optimized to a single store, though, even though the 32-bit pattern for PR
102391 doesn't. It's why I made this a separate bug report, as I thought it
indicated a likely difference in the cause of the bug.
[Bug libstdc++/102270] std::tuple<>::swap missing constexpr specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270 --- Comment #6 from Jonathan Wakely --- I think that constructor could just be deleted, but it's fixed now. Thanks.
[Bug c++/102397] Documentation of attribute syntax does not discuss C++11 / C23 attribute syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-18 Ever confirmed|0 |1
[Bug tree-optimization/102400] New: Field might miss initialization in vn_reference_insert_pieces()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400 Bug ID: 102400 Summary: Field might miss initialization in vn_reference_insert_pieces() Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- There is no initialization for vr1->result_vdef, and it may contain non-zero garbage value.
[Bug c++/102399] New: Cannot mix GCC and C++11 / C23 attribute syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102399
Bug ID: 102399
Summary: Cannot mix GCC and C++11 / C23 attribute syntax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
If one tries to mix GCC's attribute syntax (__attribute__) and with C++11 / C23
([[attribute]]), GCC rejects the code (no matter what the order of the
attributes is):
#define EXPORT __attribute__((visibility("default")))
struct [[nodiscard]] EXPORT Foo { Foo(); };
https://gcc.godbolt.org/z/W868xjeMq
While a workaround exists (by sticking to the same "kind" of attribute syntax),
it's not always possible or easy to achieve in big codebases, where for
compatibility/legacy reasons the attributes are expanded via macros and can
expand to a random combination of GCC or C++ attributes.
For comparison, Clang and MSVC allow mixed syntaxes.
[Bug c++/102398] New: thread_local works incorrectly outside of main file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102398 Bug ID: 102398 Summary: thread_local works incorrectly outside of main file Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marcelotpcruz at gmail dot com Target Milestone: --- Created attachment 51479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51479=edit thread_local_work_at_main_fails_wherever Hello, This bug is related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81915 I believe above link can be closed as it's old and the specification is a bit incorrect. The problem is not about it being inline or inside a class var, as any of those works if such are inside the file with the main(). Real problem is about variable definition outside of "main" file, so when it's only declared, the problem doesn't show, that's why inline reports the bug, it tells the compiler to define on the same line as it's defined. - - - - - When using thread_local in main file it works! -- Clean: Debug in thread_local (compiler: GNU GCC Compiler)--- Cleaned "thread_local - Debug" -- Build: Debug in thread_local (compiler: GNU GCC Compiler)--- g++.exe -Wall -fexceptions -g -O -save-temps -c C:\my_codes\thread_local\main.cpp -o obj\Debug\main.o g++.exe -o bin\Debug\thread_local.exe obj\Debug\main.o Output file is bin\Debug\thread_local.exe with size 152.48 KB Process terminated with status 0 (0 minute(s), 1 second(s)) 0 error(s), 0 warning(s) (0 minute(s), 1 second(s)) - - - - - When using thread_local outside of main file, throught #include including , it fails: -- Clean: Debug in thread_local_fail (compiler: GNU GCC Compiler)--- Cleaned "thread_local_fail - Debug" -- Build: Debug in thread_local_fail (compiler: GNU GCC Compiler)--- g++.exe -Wall -fexceptions -g -O -save-temps -c C:\my_codes\thread_local_fail\extern_thread_local.cpp -o obj\Debug\extern_thread_local.o g++.exe -Wall -fexceptions -g -O -save-temps -c C:\my_codes\thread_local_fail\main.cpp -o obj\Debug\main.o g++.exe -o bin\Debug\thread_local_fail.exe obj\Debug\extern_thread_local.o obj\Debug\main.o c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: obj\Debug\main.o:C:/Users/MarceloTPC/Documents/my_codes/thread_local_fail/extern_thread_local.cpp:4: multiple definition of `TLS init function for does_not_work_string_located_at_main[abi:cxx11]'; obj\Debug\extern_thread_local.o:C:/Users/MarceloTPC/Documents/my_codes/thread_local_fail/extern_thread_local.cpp:4: first defined here c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: obj\Debug\main.o:main.cpp:(.data+0x0): multiple definition of `__emutls_v._Z36does_not_work_string_located_at_mainB5cxx11'; obj\Debug\extern_thread_local.o:extern_thread_local.cpp:(.data+0x0): first defined here collect2.exe: error: ld returned 1 exit status Process terminated with status 1 (0 minute(s), 1 second(s)) 2 error(s), 0 warning(s) (0 minute(s), 1 second(s)) - - - - - Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/R/winlibs64_stage/inst_gcc-11.2.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++,d,jit --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs64_stage/custombuilt --with-mpfr=/d/Prog/winlibs64_stage/custombuilt --with-gmp=/d/Prog/winlibs64_stage/custombuilt --with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64_stage/gcc-11.2.0/build_mingw/mingw-w64 CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32 Thread model: posix Supported LTO compression algorithms: zlib
[Bug c++/102397] New: Documentation of attribute syntax does not discuss C++11 / C23 attribute syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397 Bug ID: 102397 Summary: Documentation of attribute syntax does not discuss C++11 / C23 attribute syntax Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dangelog at gmail dot com Target Milestone: --- Hi, The available documentation for attributes syntax https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax does not mention at all the possibility that in C++11 (and, I imagine, in C23) one can specify any GCC-specific attribute using a [[gnu::attribute]] attribute specifier, and not only the GCC-specific __attribute__((attribute)) syntax. I think it would be worth mentioning in there that this is actually OK and fully supported.
[Bug target/102016] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-2919-gfaf2b6bc527dff31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102016 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- .
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 --- Comment #6 from Jan-Benedict Glaw --- I'll fetch that patch and stuff it in the autobuilder, then let it run for nvptx, vax and a few others.
[Bug middle-end/101109] [9/10/11/12 Regression] ICE with function in the .vtable_map_vars section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101109 Andrew Pinski changed: What|Removed |Added Summary|ICE: Segmentation Fault:|[9/10/11/12 Regression] ICE |tree_check(tree_node*, char |with function in the |const*, int, char const*, |.vtable_map_vars section |tree_code) | Known to fail||4.9.0, 5.1.0, 8.1.0 Known to work||4.1.2, 4.6.4, 4.8.1, 4.8.5 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|c |middle-end Last reconfirmed||2021-09-18 Keywords||ice-on-valid-code Target Milestone|--- |9.5 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/102245] [12 Regression] false int-in-bool-context warning with shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102245 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Roger Sayle --- Fixed on mainline.
[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com Status|NEW |ASSIGNED --- Comment #13 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579747.html
[Bug lto/99449] lto1: fatal error: multiple prevailing defs for ‘_ZTIN4sdsl14rank_support_vILh1ELh1EEE’ with -msse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99449 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Keywords||ice-checking, ||ice-on-valid-code, lto Last reconfirmed||2021-09-18 --- Comment #1 from Andrew Pinski --- c++filt _ZTIN4sdsl14rank_support_vILh1ELh1EEE typeinfo for sdsl::rank_support_v<(unsigned char)1, (unsigned char)1> Without a testcase this is going to be hard to reproduce.
[Bug ipa/97303] [9/10/11 Regression] ICE during GIMPLE pass: *rebuild_cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97303 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95114 --- Comment #1 from Andrew Pinski --- Fixed for GCC 9.4.0, GCC 10.2.0 and GCC 11+ via the patch for PR 95114.
[Bug ipa/97303] [9/10/11 Regression] ICE during GIMPLE pass: *rebuild_cgraph_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97303 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.4
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2021-09-18 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- Created attachment 51478 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51478=edit Patch This patch should fix the issue.
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Actually it might be easier to change line 1291: > gcc_assert (sclass < LIM_REG_CLASSES); > > to be: > gcc_assert (sclass < LIM_REG_CLASSES && sclass >= NO_REGS); > > I don't see how -1 is coming into play ... So the requirement is NO_REGS first is documented in tm.texi so gcc_assert (sclass < LIM_REG_CLASSES && sclass >= NO_REGS);
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 --- Comment #3 from Andrew Pinski --- Note your reduced testcase is no where near what the code looks like. The code is like this: if (!(sclass < LIM_REG_CLASSES))__builtin_unreachable(); if (slcass == ALL_REGS) return; if (sclass != NO_REGS && g()) f(x_ira_class_hard_regs[slcass][0]);
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 --- Comment #2 from Andrew Pinski --- Can you attach the original full preprocessed source?
[Bug c++/102396] New: ICE when using concepts, in get, at cp/constraint.cc:2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102396
Bug ID: 102396
Summary: ICE when using concepts, in get, at
cp/constraint.cc:2637
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
This testcase (which gets accepted by Clang and MSVC) causes an ICE under
GCC-12-trunk, and an erroneous compilation error on GCC 11.2.
#include
#include
#include
#include
template struct S;
template constexpr bool is_S = false;
template constexpr bool is_S> = true;
template
struct S {
T data;
S();
explicit S(const T &);
template , bool> = false>
requires std::equality_comparable_with
friend bool operator==(const S , const U ) { return s.data == u; }
};
template
bool operator==(const S , const S ) { return a.data == b.data; }
int main() {
using SD = S;
char data[sizeof(SD) * 10];
std::span span((SD*)std::begin(data), (SD*)std::end(data));
//static_assert(std::equality_comparable::iterator>);
std::ranges::uninitialized_default_construct(span);
}
The error:
/opt/compiler-explorer/gcc-trunk-20210918/include/c++/12.0.0/concepts:280:17:
internal compiler error: in get, at cp/constraint.cc:2637
280 | { __t == __u } -> __boolean_testable;
| ^~
0x1fc77b9 internal_error(char const*, ...)
???:0
0x713d19 fancy_abort(char const*, int, char const*)
???:0
0x7970af satisfaction_cache::get()
???:0
0x79cd8a constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x9ba323 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x73f150 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
???:0
0xa2fc50 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
???:0
0x79cd42 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x79cd8a constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x9ba323 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x73f150 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
???:0
0xa2fc50 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
???:0
0x9816d7 instantiate_decl(tree_node*, bool, bool)
???:0
0x9c3e1b instantiate_pending_templates(int)
???:0
0x82a899 c_parse_final_cleanups()
???:0
[Bug middle-end/102395] [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 --- Comment #1 from Andrew Pinski --- Actually it might be easier to change line 1291: gcc_assert (sclass < LIM_REG_CLASSES); to be: gcc_assert (sclass < LIM_REG_CLASSES && sclass >= 0); I don't see how -1 is coming into play ...
[Bug middle-end/102395] New: [nvptx, vax] enum reg_class inferred as signed / unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102395 Bug ID: 102395 Summary: [nvptx, vax] enum reg_class inferred as signed / unsigned Product: gcc Version: analyzer branch Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Created attachment 51477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51477=edit Testcase Running automated testing, I get similar errors then building for --target=nvptx-none and vax-linux using a fairly recent GCC version: $ .../configure --target=nvptx-none \ --enable-werror-always \ --enable-languages=all \ --disable-gcov \ --disable-shared \ --disable-threads \ --without-headers [..] $ make all-gcc [...] [all 2021-09-13 12:37:11] /usr/lib/gcc-snapshot/bin/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 -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o lra-constraints.o -MT lra-constraints.o -MMD -MP -MF ./.deps/lra-constraints.TPo ../../gcc/gcc/lra-constraints.c [all 2021-09-13 12:37:20] In function 'bool check_and_process_move(bool*, bool*)', [all 2021-09-13 12:37:20] inlined from 'bool curr_insn_transform(bool)' at ../../gcc/gcc/lra-constraints.c:4092:33: [all 2021-09-13 12:37:20] ../../gcc/gcc/lra-constraints.c:1317:56: error: array subscript -1 is below array bounds of 'short int [2][16]' [-Werror=array-bounds] [all 2021-09-13 12:37:20] 1317 | reg_renumber[dregno] = ira_class_hard_regs[dclass][0]; [all 2021-09-13 12:37:20] In file included from ../../gcc/gcc/lra-constraints.c:123: [all 2021-09-13 12:37:20] ../../gcc/gcc/ira.h: In function 'bool curr_insn_transform(bool)': [all 2021-09-13 12:37:20] ../../gcc/gcc/ira.h:85:9: note: while referencing 'target_ira::x_ira_class_hard_regs' [all 2021-09-13 12:37:20]85 | short x_ira_class_hard_regs[N_REG_CLASSES][FIRST_PSEUDO_REGISTER]; [all 2021-09-13 12:37:20] | ^ [all 2021-09-13 12:37:20] In function 'bool check_and_process_move(bool*, bool*)', [all 2021-09-13 12:37:20] inlined from 'bool curr_insn_transform(bool)' at ../../gcc/gcc/lra-constraints.c:4092:33: [all 2021-09-13 12:37:20] ../../gcc/gcc/lra-constraints.c:1324:56: error: array subscript -1 is below array bounds of 'short int [2][16]' [-Werror=array-bounds] [all 2021-09-13 12:37:20] 1324 | reg_renumber[sregno] = ira_class_hard_regs[sclass][0]; [all 2021-09-13 12:37:20] In file included from ../../gcc/gcc/lra-constraints.c:123: [all 2021-09-13 12:37:20] ../../gcc/gcc/ira.h: In function 'bool curr_insn_transform(bool)': [all 2021-09-13 12:37:20] ../../gcc/gcc/ira.h:85:9: note: while referencing 'target_ira::x_ira_class_hard_regs' [all 2021-09-13 12:37:20]85 | short x_ira_class_hard_regs[N_REG_CLASSES][FIRST_PSEUDO_REGISTER]; [all 2021-09-13 12:37:20] | ^ [all 2021-09-13 12:37:26] cc1plus: all warnings being treated as errors [all 2021-09-13 12:37:26] make[1]: *** [Makefile:1142: lra-constraints.o] Error 1 [all 2021-09-13 12:37:26] make[1]: Leaving directory '/var/lib/laminar/run/gcc-nvptx-none/8/toolchain-build/gcc' [all 2021-09-13 12:37:26] make: *** [Makefile:4407: all-gcc] Error 2 (Initial report can be found at https://gcc.gnu.org/pipermail/gcc/2021-September/237237.html) Martin Sebor already had a look at it (cf. https://gcc.gnu.org/pipermail/gcc/2021-September/237383.html) and suggested to explicitely make reg_class an unsigned enum, or to add gcc_unreachable() for < 0 to indicate the non-negativeness of sclass/dclass. Preprocessed / minimized testcase attached (based on --target=nvptx-none), build with a recent GCC: g++ -c -O2 -Wall -o lra-constraints.o lra-constraints.ii
[Bug debug/63581] undefined references in debug_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63581 Andrew Pinski changed: What|Removed |Added CC||arnetheduck at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 64593 has been marked as a duplicate of this bug. ***
[Bug bootstrap/64593] libmpfr.a undefined reference to `.L222' when doing make profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64593 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 63581. *** This bug has been marked as a duplicate of bug 63581 ***
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Last reconfirmed|2010-04-22 16:54:18 |2021-9-18
--- Comment #7 from Andrew Pinski ---
The code is now in config/gcc-plugin.m4 and still does not use ${OBJDIR} or
${NM} (for the darwin case).
[Bug bootstrap/54353] bootstrap-debug-ckovw bootstrap fails because of -fcompare-debug-not-overridden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54353 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||build Last reconfirmed||2021-09-18 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- So I just tested this. The problem for me is configure in libcpp overrides the CFLAGS just to see if -g is accepted and/or when testing to see which style of dependancy gcc is emitting. I don't think there is a way to get this fixed without major changes to autoconf ...
