[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Any caller of bar should be fine. The localentry value of 1 means it is advertised as having no requirement on r2 or r12 and r2 is *not* preserved. A call that uses R_PPC64_REL24 to bar ought to have an r2 saving stub inserted by the linker and the nop after the call changed to restore r2. GNU ld will do exactly that. 1540 <0047.long_branch.bar>: 1540: 18 00 41 f8 std r2,24(r1) 1544: 4c 02 00 48 b 1790 ... 15a0 : 15a0: 02 10 40 3c lis r2,4098 15a4: 00 7f 42 38 addir2,r2,32512 15a8: a6 02 08 7c mflrr0 15ac: 00 00 00 60 nop 15b0: 20 80 62 e8 ld r3,-32736(r2) 15b4: 10 00 01 f8 std r0,16(r1) 15b8: e1 ff 21 f8 stdur1,-32(r1) 15bc: 85 ff ff 4b bl 1540 <0047.long_branch.bar> 15c0: 18 00 41 e8 ld r2,24(r1) There isn't a problem if bar is passed the address of a non-pcrel function in a shared library as it is in your example. The call in bar will go to the global entry point of foo, which will set up r2. The same thing happens when linking against foo.o, the function pointer address is that of the global entry of foo. [amodra@gcc135 p10-interop]$ ./smain Hello from foo Hello, World! (My dynamic main won't run on gcc135 due to my build machine having a more recent glibc, but I'm confident it would run if I fixed that.) I don't see any problem here other than (presumably) missing linker support.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 --- Comment #4 from David Binderman --- Only one pass at reduction, leaving 14 revisions, but this commit looks to be a hot candidate: commit e8109bd87766be88e83fe88a44433dae16358a02 Author: Martin Jambor Date: Fri Feb 3 13:28:24 2023 +0100 ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384)
[Bug c/108941] Error: operand type mismatch for `shr' with binutils master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941 --- Comment #17 from Jakub Jelinek --- (In reply to jbeulich from comment #16) > I can only repeat: Unless the anomaly is properly called out in non-internal > documentation, I continue to think there's a bug here. And the reference to For inline asm, the only important things besides the exact values are the mode (for integral scalar modes that determines mostly how many bits it has), constraints (which determine where it can be passed and limit set of valid values) and optional modifiers which change how it is printed. > Clang getting it right, which you simply put off, isn't entirely meaningless > imo (I agree we're talking about a GNU extension here, but that doesn't > imply only GNU tools can get it right). Clang definitely doesn't implement the GNU extension correctly, far from it, because it broke the basic premise that it is a black box for the compiler on which it performs a text replacement. It instead parses and assembles the text, so behaves completely differently from how the extension was defined. So it can't be then safely used for optimization barriers, one can't use there something not really valid in the assembler etc.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 David Binderman changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from David Binderman --- Three C++ changes and Martin's change. Adding Martin for their best advice.
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Gaius Mulley --- > The hand built modules were not changed to include the libname. (UnixArgs, > ldtoa, dtoa for the tool pge). The patch corrects the hand built modules and > also includes fixes for the attribute noreturn warnings generated when > compiling M2RTS.cc. Unfortunately, this didn't help: the SEGV and caller/callee mismatch remain exactly the same.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 --- Comment #6 from David Binderman --- As expected: $ git bisect bad e8109bd87766be88 e8109bd87766be88e83fe88a44433dae16358a02 is the first bad commit commit e8109bd87766be88e83fe88a44433dae16358a02 Author: Martin Jambor Date: Fri Feb 3 13:28:24 2023 +0100 ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384)
[Bug sanitizer/108963] New: ASAN produces wrong line number in the report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963
Bug ID: 108963
Summary: ASAN produces wrong line number in the report
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, ASAN at -O1 and above always produces the wrong line
number. I've found quite some cases that have this issue.
Compiler explorer: https://godbolt.org/z/hscP9T78M
% cat a.c
union a {
int b;
};
char c;
int d;
static long e(int *f) {
for (; c <= 1;c++)
*(f + 1) |= 2;
return 0;
}
int main() {
union a g = {};
e(&d);
&g;
}
%
% gcc-tk -O0 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404184
at pc 0x004011d6 bp 0x7ffea18cbe60 sp 0x7ffea18cbe58
READ of size 4 at 0x00404184 thread T0
#0 0x4011d5 in e /a.c:8
#1 0x4012f1 in main /a.c:13
...
%
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404144
at pc 0x00401289 bp 0x74114850 sp 0x74114848
READ of size 4 at 0x00404144 thread T0
#0 0x401288 in main /a.c:12
...
%
Maybe a fundunmentally similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023
[Bug c/108964] New: Attribute target should be implemented for C backend (not only c++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964
Bug ID: 108964
Summary: Attribute target should be implemented for C backend
(not only c++)
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rouca at debian dot org
Target Milestone: ---
Hi,
The following program fail to compile with gcc but compile with g++
On the debian side we will like to have it see
https://wiki.debian.org/InstructionSelection
__attribute__((target("default")))
int test_fn()
{
return 1;
}
__attribute__((target("sse2")))
int test_fn()
{
return 0;
}
int main()
{
return test_fn();
}
Bastien (rouca for debian)
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #19 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:822a11a1e642e0abe92a996e7033a5066905a447 commit r13-6372-g822a11a1e642e0abe92a996e7033a5066905a447 Author: Jonathan Wakely Date: Sat Feb 25 14:28:36 2023 + libstdc++: Do not use memmove for 1-element ranges [PR108846] This avoids overwriting tail padding when algorithms like std::copy are used to write a single value through a pointer to a base subobject. The pointer arithmetic on a Base* is valid for N==1, but the copy/move operation needs to be done using assignment, not a memmove or memcpy of sizeof(Base) bytes. Instead of putting a check for N==1 in all of copy, copy_n, move etc. this adds it to the __copy_move and __copy_move_backward partial specializations used for trivially copyable types. When N==1 those partial specializations dispatch to new static member functions of the partial specializations for non-trivial types, so that a copy/move assignment is done appropriately for the _IsMove constant. libstdc++-v3/ChangeLog: PR libstdc++/108846 * include/bits/stl_algobase.h (__copy_move) Add __assign_one static member function. (__copy_move): Likewise. (__copy_move): Do not use memmove for a single value. (__copy_move_backward): Likewise. * testsuite/25_algorithms/copy/108846.cc: New test. * testsuite/25_algorithms/copy_backward/108846.cc: New test. * testsuite/25_algorithms/copy_n/108846.cc: New test. * testsuite/25_algorithms/move/108846.cc: New test. * testsuite/25_algorithms/move_backward/108846.cc: New test.
[Bug libstdc++/108952] [10/11/12/13 Regression] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8e342c04550466ab088c33746091ce7f3498ee44 commit r13-6373-g8e342c04550466ab088c33746091ce7f3498ee44 Author: Jonathan Wakely Date: Mon Feb 27 22:34:57 2023 + libstdc++: Fix uses_allocator_construction_args for pair [PR108952] This implements LWG 3527 which fixes the handling of pair in std::uses_allocator_construction_args. libstdc++-v3/ChangeLog: PR libstdc++/108952 * include/bits/uses_allocator_args.h (uses_allocator_construction_args): Implement LWG 3527. * testsuite/20_util/pair/astuple/get-2.cc: New test. * testsuite/20_util/scoped_allocator/108952.cc: New test. * testsuite/20_util/uses_allocator/lwg3527.cc: New test.
[Bug libstdc++/108952] [10/11/12 Regression] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 Jonathan Wakely changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |Regression in |Regression in |uses_allocator_construction |uses_allocator_construction |_args for pair of rvalue|_args for pair of rvalue |references |references --- Comment #8 from Jonathan Wakely --- Fixed on trunk so far.
[Bug c++/108965] New: g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
Bug ID: 108965
Summary: g++: unable to parse c11 _Generics
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisfriedt at gmail dot com
Target Milestone: ---
G++ version 11.3.0 fails to parse the C11 _Generic keyword. I would suspect
that earlier versions also fail to do this and likely also that later versions
fail as well.
gcc --version
gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It's not clear to me if any part of the ISO C++ standard requires a C++
compiler to parse C11 _Generic, but it certainly can make life less pleasant,
as the equivalent C++ code can sometimes rely on static inline constexpr
templates which are apparently "not cool" until C++14. This particularly
affects people who are using somewhat older C++ toolchains that do not yet
support C++14.
LLVM has no problem, OTOH.
Sample taken from https://en.cppreference.com/w/c/language/generic
```
#include
#include
// Possible implementation of the tgmath.h macro cbrt
#define cbrt(X) _Generic((X), \
long double: cbrtl, \
default: cbrt, \
float: cbrtf \
)(X)
int main(void)
{
double x = 8.0;
const float y = 3.375;
printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
printf("cbrtf(3.375) = %f\n", cbrt(y)); // converts const float to float,
// then selects cbrtf
}
```
```
g++ -o /tmp/main /tmp/main.cpp
/tmp/main.cpp: In function ‘int main()’:
/tmp/main.cpp:6:15: error: expected primary-expression before ‘long’
6 | long double: cbrtl, \
| ^~~~
/tmp/main.cpp:15:32: note: in expansion of macro ‘cbrt’
15 | printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
|^~~~
/tmp/main.cpp:7:19: error: expected primary-expression before ‘default’
7 | default: cbrt, \
| ^~~
/tmp/main.cpp:15:32: note: in expansion of macro ‘cbrt’
15 | printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
|^~~~
/tmp/main.cpp:8:21: error: expected primary-expression before ‘float’
8 | float: cbrtf \
| ^
/tmp/main.cpp:15:32: note: in expansion of macro ‘cbrt’
15 | printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
|^~~~
/tmp/main.cpp:5:17: error: ‘_Generic’ was not declared in this scope
5 | #define cbrt(X) _Generic((X), \
| ^~~~
/tmp/main.cpp:15:32: note: in expansion of macro ‘cbrt’
15 | printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
|^~~~
/tmp/main.cpp:6:15: error: expected primary-expression before ‘long’
6 | long double: cbrtl, \
| ^~~~
/tmp/main.cpp:16:35: note: in expansion of macro ‘cbrt’
16 | printf("cbrtf(3.375) = %f\n", cbrt(y)); // converts const float to
float,
| ^~~~
/tmp/main.cpp:7:19: error: expected primary-expression before ‘default’
7 | default: cbrt, \
| ^~~
/tmp/main.cpp:16:35: note: in expansion of macro ‘cbrt’
16 | printf("cbrtf(3.375) = %f\n", cbrt(y)); // converts const float to
float,
| ^~~~
/tmp/main.cpp:8:21: error: expected primary-expression before ‘float’
8 | float: cbrtf \
| ^
/tmp/main.cpp:16:35: note: in expansion of macro ‘cbrt’
16 | printf("cbrtf(3.375) = %f\n", cbrt(y)); // converts const float to
float,
| ^~~~
```
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #1 from Jonathan Wakely --- (In reply to Christopher Friedt from comment #0) > It's not clear to me if any part of the ISO C++ standard requires a C++ > compiler to parse C11 _Generic, It's very clear that it doesn't, _Generic is never mentioned anywhere in the C++ standard. > but it certainly can make life less > pleasant, as the equivalent C++ code can sometimes rely on static inline > constexpr templates which are apparently "not cool" until C++14. This Why not? What exactly is the equivalent code you're referring to? C++ has never needed _Generic because it supports function overloading.
[Bug c++/108966] New: Inheriting consteval constructor makes it constexpr in the derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966
Bug ID: 108966
Summary: Inheriting consteval constructor makes it constexpr in
the derived class
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@arne-mertz.de
Target Milestone: ---
Consider the following code:
```
struct X
{
consteval X(int) {};
};
struct T : X
{
using X::X;
};
constexpr T t(22);
```
The using directive (1) should lead to a `consteval T::T(int)`. However, the
compiler errors with message
```
: In constructor 'constexpr T::T(double&&) [inherited from X]':
:8:14: error: 'this' is not a constant expression
8 | using X::X;
```
This indicates that the inherited constructor is considered `constexpr` instead
of `consteval` and is therefore unable to call the `consteval` base class
constructor.
See it in action: https://godbolt.org/z/K6T6f1691
Note:
- this does not happen when the constructor is replaced with `X::X() = default`
and no initializer is given to `t`, but a similar error appears with `X::X()
{}`
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- I've commented on the github issue. There is no G++ bug here.
[Bug testsuite/108942] ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Let me fix this.
[Bug testsuite/108942] ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:41c02eeb309b3be58683be8f9961f3894b6fb4c7 commit r13-6374-g41c02eeb309b3be58683be8f9961f3894b6fb4c7 Author: Richard Biener Date: Tue Feb 28 11:36:01 2023 +0100 testsuite/108942 - use sizetype in GIMPLE FE testcase The following properly uses __SIZETYPE__ for pointer offsets. PR testsuite/108942 * gcc.dg/torture/ssa-fre-7.c: Use __SIZETYPE__.
[Bug testsuite/108942] ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/108947] [13 Regression] wrong code with -O2 -fno-forward-propagate and vector compare on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/108949] Optimize shift counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108949 --- Comment #1 from Richard Biener --- There's still the goal to get rid of SHIFT_COUNT_TRUNCATED, that is, make the semantics of RTL (and most definitely GIMPLE) independent of target macros/hooks.
[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894 --- Comment #14 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c7728805a7107444683290cd629d13f089130a0d commit r13-6375-gc7728805a7107444683290cd629d13f089130a0d Author: Jakub Jelinek Date: Tue Feb 28 11:38:46 2023 +0100 ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894] While this isn't really a regression, the -fstrict-flex-arrays* option is new in GCC 13 and so I think we should make -fsanitize=bounds play with it well from the beginning. The current behavior is that -fsanitize=bounds considers all trailing arrays as flexible member-like arrays and both -fsanitize=bounds and -fsanitize=bounds-strict because of a bug don't even instrument [0] arrays at all, not as trailing nor when followed by other members. I think -fstrict-flex-arrays* options can be considered as language mode changing options, by default flexible member-like arrays are handled like flexible arrays, but that option can change the set of the arrays which are treated like that. So, -fsanitize=bounds should change with that on what is considered acceptable and what isn't. While -fsanitize=bounds-strict should reject them all always to continue previous behavior. The following patch implements that. To support [0] array instrumentation, I had to change the meaning of the bounds argument to .UBSAN_BOUNDS, previously it was the TYPE_MAX_VALUE of the domain unless ignore_off_by_one (used for taking address of the array element rather than accessing it; in that case 1 is added to the bound argument) and the later lowered checks were if (index > bound) report_failure (). The problem with that is that for [0] arrays where (at least for C++) the max value is all ones, for accesses that condition will be never true; for addresses of elements it was working (in C++) correctly before. This patch changes it to add 1 + ignore_off_by_one, so -1 becomes 0 or 1 for &array_ref and changing the lowering to be if (index >= bound) report_failure (). Furthermore, as C represents the [0] arrays with NULL TYPE_MAX_VALUE, I treated those like the C++ ones. 2023-02-28 Jakub Jelinek PR sanitizer/108894 gcc/ * ubsan.cc (ubsan_expand_bounds_ifn): Emit index >= bound comparison rather than index > bound. * gimple-fold.cc (gimple_fold_call): Use tree_int_cst_lt rather than tree_int_cst_le for IFN_UBSAN_BOUND comparison. * doc/invoke.texi (-fsanitize=bounds): Document that whether flexible array member-like arrays are instrumented or not depends on -fstrict-flex-arrays* options of strict_flex_array attributes. (-fsanitize=bounds-strict): Document that flexible array members are not instrumented. gcc/c-family/ * c-common.h (c_strict_flex_array_level_of): Declare. * c-common.cc (c_strict_flex_array_level_of): New function, moved and renamed from c-decl.cc's strict_flex_array_level_of. * c-ubsan.cc (ubsan_instrument_bounds): Fix comment typo. For C check c_strict_flex_array_level_of whether a trailing array should be treated as flexible member like. Handle C [0] arrays. Add 1 + index_off_by_one rather than index_off_by_one to bounds and use tree_int_cst_lt rather than tree_int_cst_le for idx vs. bounds comparison. gcc/c/ * c-decl.cc (strict_flex_array_level_of): Move to c-common.cc and rename to c_strict_flex_array_level_of. (is_flexible_array_member_p): Adjust caller. gcc/testsuite/ * gcc.dg/ubsan/bounds-4.c: New test. * gcc.dg/ubsan/bounds-4a.c: New test. * gcc.dg/ubsan/bounds-4b.c: New test. * gcc.dg/ubsan/bounds-4c.c: New test. * gcc.dg/ubsan/bounds-4d.c: New test. * g++.dg/ubsan/bounds-1.C: New test.
[Bug target/108950] [11/12/13 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr'; error: type mismatch in 'widen_sum_expr') since r11-418-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Target Milestone|--- |11.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I will have a look.
[Bug libstdc++/108952] [10/11/12 Regression] Regression in uses_allocator_construction_args for pair of rvalue references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Priority|P3 |P2
[Bug tree-optimization/108953] inefficient codegen for trivial equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I think it only makes sense to combine the compares when the operand(s) are from memory which means the machinery we have in load/store merging becomes useful which means we eventually want to do this in this very pass (or in the bswap pass). The alternative would be ifcombine but then the order of the compares in the source could be arbitrary, so it doesn't really fit that one for the most optimal result. There's also a related vectorization bug in case the SLP vectorizer is the target to look at.
[Bug c/108954] ICE with invalid gimple source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108954 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-28 Blocks||101057 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Well, we're (ab-)using the GIMPLE verifiers for error reporting - that we have some places in build2 that ICE (for the sake of early catching errors) is unfortunate. But the intent was to _not_ re-implement the GIMPLE verifier in the GIMPLE frontend. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 [Bug 101057] [gimplefe] GIMPLE frontend issues
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2023-02-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #3 from Christopher Friedt --- All you need to do is look at the example above pulled directly from cppreference.com, but please simply gaslight the user if that's an easier path to resolution for you.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #4 from Andrew Pinski --- (In reply to Christopher Friedt from comment #3) > All you need to do is look at the example above pulled directly from > cppreference.com, but please simply gaslight the user if that's an easier > path to resolution for you. There is no gaslighting going on. In fact now you just being abusive for what end? The facts are: The _Generic is only part of the C standard and not part of the C++ standard. They are two different things. Gcc's C++ frontend has never implemented _Generic support. GCC's C frontend does though. The C and C++ frontends in gcc do share some code but the parser has never been shared.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus --- Created attachment 54554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54554&action=edit Draft patch - adds and uses tree_operand_sideeff_hash The patch does what I wrote last: Adds The problem (for the Fortran testcase but probably for both) occurs for omp_mapped_by_containing_struct's omp_mapping_group **wholestruct = grpmap->get (wsdecl); where 'wsdecl' is 'x.a'. If I look at operand_equal_p – invoked by 'tree_operand_hash::equal, I get 'true' without 'volatile' and 'false' with. The only difference is "side-effects volatile" for the component_ref and that "component_ref 0x76e25e70" are not identical but different tree; the arguments etc. are identical. In operand_compare::operand_equal_p there is: if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST) && (TREE_CODE (arg0) == SAVE_EXPR || (flags & OEP_MATCH_SIDE_EFFECTS) || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1 return true; Thus, it seems as if we need a variant of gcc/tree-hash-traits.h that passes not 0 but OEP_MATCH_SIDE_EFFECTS as flag to operand_equal_p.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #5 from Jonathan Wakely --- (In reply to Christopher Friedt from comment #3) > All you need to do is look at the example above pulled directly from > cppreference.com, but please simply gaslight the user if that's an easier > path to resolution for you. WTF? How am I gaslighting you? Your example is from cppreference.com/w/c/ which is the **C** reference. Look at the breadcrumb thingy at the top of the page: "C / C language / Expressions" The C++ references are under cppreference.com/w/cpp/ instead of /w/c/ Go to https://en.cppreference.com/w/Main_Page and check that it has both C++ and C references on that site, with different URLs.
[Bug c++/108967] New: internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
Bug ID: 108967
Summary: internal compiler error: in expand_debug_expr, at
cfgexpand.cc:5450
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
Created attachment 54555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54555&action=edit
Preprocessed source
I cannot compile highway on arm64 with gcc-13 anymore.
Compilation fais with:
% /usr/lib/gcc-snapshot/bin/g++ -freport-bug -DHWY_SHARED_DEFINE
-I"/home/malat/highway-1.0.4~git20230227.dc5c141" -g -O2
-ffile-prefix-map=/home/malat/highway-1.0.4~git20230227.dc5c141=.
-fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-builtin-macro-redefined
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla
-Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1
-DGTEST_HAS_PTHREAD=1 -MD -MT
CMakeFiles/arithmetic_test.dir/hwy/tests/arithmetic_test.cc.o -MF
CMakeFiles/arithmetic_test.dir/hwy/tests/arithmetic_test.cc.o.d -o
CMakeFiles/arithmetic_test.dir/hwy/tests/arithmetic_test.cc.o -c
"/home/malat/highway-1.0.4~git20230227.dc5c141/hwy/tests/arithmetic_test.cc"
unit-size
align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x936c5930 precision:16 min max
pointer_to_this >
unsigned V8HI
size
unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x333bf348 nunits:8>
readonly constant
arg:0
unsigned V16QI size unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type
0x5d64c690 nunits:16
pointer_to_this >
constant npatterns:1 nelts-per-pattern:3
elt:0:
elt:1:
elt:2: >
arg:1
constant npatterns:1 nelts-per-pattern:3
elt:0:
elt:1: elt:2: >>
during RTL pass: expand
In file included from
/home/malat/highway-1.0.4~git20230227.dc5c141/hwy/foreach_target.h:59,
from
/home/malat/highway-1.0.4~git20230227.dc5c141/hwy/tests/arithmetic_test.cc:21:
/home/malat/highway-1.0.4~git20230227.dc5c141/hwy/tests/arithmetic_test.cc: In
function 'void hwy::N_EMU128::TestSaturatingArithmeticOverflow::operator()(T,
D) [with T = unsigned char; D = hwy::N_EMU128::Simd]':
/home/malat/highway-1.0.4~git20230227.dc5c141/hwy/tests/arithmetic_test.cc:126:21:
internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
126 | HWY_NOINLINE void operator()(T /*unused*/, D d) {
| ^~~~
0x16c4083 expand_debug_expr
../../src/gcc/cfgexpand.cc:5450
0x16c5343 expand_debug_expr
../../src/gcc/cfgexpand.cc:5311
0x16c34ef expand_debug_expr
../../src/gcc/cfgexpand.cc:4490
0x16c5343 expand_debug_expr
../../src/gcc/cfgexpand.cc:5311
0x16c3457 expand_debug_expr
../../src/gcc/cfgexpand.cc:4463
0x16c5343 expand_debug_expr
../../src/gcc/cfgexpand.cc:5311
0x16c35e7 expand_debug_expr
../../src/gcc/cfgexpand.cc:4764
0x16c5343 expand_debug_expr
../../src/gcc/cfgexpand.cc:5311
0x13b0aa3 expand_debug_locations
../../src/gcc/cfgexpand.cc:5648
0x13b0aa3 execute
../../src/gcc/cfgexpand.cc:6825
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See for instructions.
Preprocessed source stored into /tmp/ccEsr3zo.out file, please attach this to
your bugreport.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #6 from Christopher Friedt --- It's supported OOTB in `clang++` but fails in `g++`. The example above is the simplest example that illustrates the issue. I am not being abusive, but it certainly did feel like gaslighting to read "you're doing it wrong" / close invalid without any consideration. Yes, the example is valid C. Yes, the example compiles under `clang++`. No, the example does not compile under `g++`. Thanks for following up! Although it's getting kind of condescending now.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #7 from Jonathan Wakely --- (In reply to Christopher Friedt from comment #6) > It's supported OOTB in `clang++` but fails in `g++`. Nobody is disputing that, but Clang supports lots of things that aren't valid in C++ and aren't supported by G++, and G++ supports things that aren't valid in C++ and aren't supported by Clang. That's not a bug. > The example above is the simplest example that illustrates the issue. Yes, and it's not valid C++. > I am not being abusive, but it certainly did feel like gaslighting to read > "you're doing it wrong" / close invalid without any consideration. I commented explaining that it's not in the C++ standard, and followed up in the github issue where the real bug is. That's hardly "without consideration". I've shown how to fix your C++ code to make it valid in C++11, and pointed out a problem in your C code using _Generic. I didn't have to do any of that, and I certainly won't bother doing so again.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #8 from Christopher Friedt --- My code is clearly valid C++ according to g++ :-) Thanks for your help in any case. On Tue, Feb 28, 2023, 7:38 AM redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 > > --- Comment #7 from Jonathan Wakely --- > (In reply to Christopher Friedt from comment #6) > > It's supported OOTB in `clang++` but fails in `g++`. > > Nobody is disputing that, but Clang supports lots of things that aren't > valid > in C++ and aren't supported by G++, and G++ supports things that aren't > valid > in C++ and aren't supported by Clang. That's not a bug. > > > The example above is the simplest example that illustrates the issue. > > Yes, and it's not valid C++. > > > I am not being abusive, but it certainly did feel like gaslighting to > read > > "you're doing it wrong" / close invalid without any consideration. > > I commented explaining that it's not in the C++ standard, and followed up > in > the github issue where the real bug is. That's hardly "without > consideration". > I've shown how to fix your C++ code to make it valid in C++11, and pointed > out > a problem in your C code using _Generic. I didn't have to do any of that, > and I > certainly won't bother doing so again. > > -- > You are receiving this mail because: > You reported the bug.
[Bug c/108968] New: fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
Bug ID: 108968
Summary: fanalyzer false positive with the uninitalised-ness of
the stack pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.cooper3 at citrix dot com
Target Milestone: ---
I experimented with -fanalyzer on Xen, given all the recent work on Linux.
We're quite similar, but one area where we are very different is accessing
per-cpu variables.
For architectural reasons (i.e. because we were virtualising Linux, and Linux
uses %gs for its per-cpu variables), Xen doesn't. In Xen, we have a block of
metadata at the base of the stack, and the stack suitably aligned such that we
can do something like this:
static inline struct cpu_info *get_cpu_info(void)
{
register unsigned long sp asm("rsp");
return (struct cpu_info *)((sp | (STACK_SIZE - 1)) + 1) - 1;
}
Which turns into roughly:
ptr = ((rsp | 0x7fff) + 1) - sizeof(struct cpu_info)
which is correct and work suitably due to the alignment of the stack in the
first place.
Unfortunately, it triggers:
./arch/x86/include/asm/current.h:95:5: error: use of uninitialized value 'sp'
[CWE-457] [-Werror=analyzer-use-of-uninitialized-value]
reliably, every time macros such as `current` get expanded, which is
everywhere.
The reality is that the stack pointer is never uninitialised. It is
unpredictable in the general case, but implementations can account for and
remove that unpredictability.
The normal trick to hide a variable from uninitialised handling (e.g. to asm(""
: "+g"(var)); ) doesn't work, as it suffers from the same error.
Is there any way to tell fanalyzer that this value really isn't uninitialised?
I can't see anything obvious.
I can work around the warning by doing:
unsigned long sp;
asm ( "mov %%rsp, %0" : "=r" (sp) );
but this impacts code generation quite substantially. This primitive is used
all over the place, and the regular C form undergoes far better CSE than the
explicit mov to retrieve the stack pointer.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965
--- Comment #9 from Jonathan Wakely ---
(In reply to Christopher Friedt from comment #8)
> My code is clearly valid C++ according to g++ :-)
Maybe you mean clang++ but even then, no it's not:
$ clang++ -pedantic gen.cc
gen.cc:15:32: warning: '_Generic' is a C11 extension [-Wc11-extensions]
printf("cbrt(8.0) = %f\n", cbrt(x)); // selects the default cbrt
^
gen.cc:5:17: note: expanded from macro 'cbrt'
#define cbrt(X) _Generic((X), \
^
gen.cc:16:35: warning: '_Generic' is a C11 extension [-Wc11-extensions]
printf("cbrtf(3.375) = %f\n", cbrt(y)); // converts const float to float,
^
gen.cc:5:17: note: expanded from macro 'cbrt'
#define cbrt(X) _Generic((X), \
^
2 warnings generated.
It's a non-standard extension, not valid C++.
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #10 from Christopher Friedt --- Thanks - I wasn't using -pedantic, but you have certainly proven stuff.
[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447 --- Comment #7 from Vincent Lefèvre --- On https://godbolt.org/z/Yx7b1d this still fails with "x86-64 gcc (trunk)". Moreover, several releases are affected: 11.1, 11.2, 11.3, 12.1, 12.2.
[Bug c++/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Reproduced now, reducing and bisecting.
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 Gaius Mulley changed: What|Removed |Added Attachment #54553|0 |1 is obsolete|| --- Comment #4 from Gaius Mulley --- Created attachment 54556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54556&action=edit Proposed fix v3 Apologies - I mischecked the wrong UnixArgs.c. Here is version 3 with the pge UnixArgs.c changed to include the library name.
[Bug libstdc++/108969] New: [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Bug ID: 108969 Summary: [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- The fix for PR 44952 is an ABI change because code compiled with GCC 13 relies on the init happening once in the library. If a binary compiled with GCC 13 uses libstdc++.so.6.0.30 at runtime then it will segfault when trying to use the streams. Even though this scenario is unsupported, it would be much better to get an error from ld.so
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-02-28 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44952 Target Milestone|--- |13.0
[Bug libstdc++/108630] build failure with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92192 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > I suggest simply not using LTO for libstdc++. LTO will almost certainly break src/c++98/globals_io.cc so I don'tthink we can support building libstdc++ with LTO for now.
[Bug c/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #1 from Andreas Schwab --- Can you use __builtin_frame_address instead?
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Can we do it without actually introducing some code to what gets executed?
Like,
asm (".global _ZN9__gnu_cxx19needs_iostream_initE");
in place where it was done before?
The above results in the symbol being listed in .symtab, but no actual runtime
relocations against it.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -43,6 +43,12 @@
// In macro form:
// _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
+#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION
+# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31")))
+#else
+# define SYMVER(sym)
+#endif
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -53,20 +59,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__attribute__ ((aligned(__alignof__(istream;
typedef char fake_ostream[sizeof(ostream)]
__attribute__ ((aligned(__alignof__(ostream;
- fake_istream cin;
- fake_ostream cout;
- fake_ostream cerr;
- fake_ostream clog;
+ SYMVER(_ZSt3cin) fake_istream cin;
+ SYMVER(_ZSt4cout) fake_ostream cout;
+ SYMVER(_ZSt4cerr) fake_ostream cerr;
+ SYMVER(_ZSt4clog) fake_ostream clog;
#ifdef _GLIBCXX_USE_WCHAR_T
typedef char fake_wistream[sizeof(wistream)]
__attribute__ ((aligned(__alignof__(wistream;
typedef char fake_wostream[sizeof(wostream)]
__attribute__ ((aligned(__alignof__(wostream;
- fake_wistream wcin;
- fake_wostream wcout;
- fake_wostream wcerr;
- fake_wostream wclog;
+ SYMVER(_ZSt4wcin) fake_wistream wcin;
+ SYMVER(_ZSt5wcout) fake_wostream wcout;
+ SYMVER(_ZSt5wcerr) fake_wostream wcerr;
+ SYMVER(_ZSt5wclog) fake_wostream wclog;
#endif
#include "ios_base_init.h"
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #3 from Jakub Jelinek --- You're right, it can be done just on the library side. Though, only for GNU symbol versioning, I think the Solaris one doesn't allow having one symbol with multiple symbol versions.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #4 from Jonathan Wakely --- The patch above means that a program using cout (or any of the standard streams) gets: 00404040 B _ZSt4cout@GLIBCXX_3.4.31 instead of: 00404040 B _ZSt4cout@GLIBCXX_3.4 And then it fails to run with the older libstdc++.so: ./a.out: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by ./a.out) But I agree that it's not a complete solution for all targets, just a quick fix for linux distros where this is most likely to cause problems today.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #5 from Jakub Jelinek --- Even for the partial Linux solution, you need to make sure that those variables are exported as both _ZSt5wcout@GLIBCXX_3.4 and _ZSt5wcout@@GLIBCXX_3.4.31 (same address i.e. aliases).
[Bug c++/108965] g++: unable to parse c11 _Generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108965 --- Comment #11 from Christopher Friedt --- (In reply to Jonathan Wakely from comment #9) > (In reply to Christopher Friedt from comment #8) > > My code is clearly valid C++ according to g++ :-) > > Maybe you mean clang++ but even then, no it's not: I was talking about the code at the linked PR. It's valid C++11 according to g++ (and clang++). I was not talking about the cppreference.com example (which is not my code, which is what you seem to be referencing as my code). I did not compile the cppreference.com code with -pedantic, but if you feel you need to in order to illustrate that you are right here, by all means. I can also run a command that illustrates my point as well. See? $ clang++ -std=c++11 -o /tmp/main /tmp/main.cpp $ echo $? 0 So really, if you're trying to tell me that my observations did not actually occur, that is, by definition, gaslighting. > I commented explaining that it's not in the C++ standard, and followed up > in the github issue where the real bug is. The comments you made on the github pr do not highlight "where the real bug is" because the code is not buggy - it produces the desired results. > "I didn't have to do any of that, and I certainly won't bother doing so again" Works for me!
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #6 from Florian Weimer --- (In reply to Jonathan Wakely from comment #2) > --- a/libstdc++-v3/src/c++98/globals_io.cc > +++ b/libstdc++-v3/src/c++98/globals_io.cc > @@ -43,6 +43,12 @@ > // In macro form: > // _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2) > > +#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION > +# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31"))) > +#else > +# define SYMVER(sym) > +#endif Is there anything that prevents these symbol versions getting added for libstdc++.a? I think that could be problematic because a custom DSO typically will not have a version node for GLIBCXX_3.4.31.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #7 from Jonathan Wakely --- I think they're exported correctly with both versions: $ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c' 0025d7a0 B _ZSt3cin@@GLIBCXX_3.4 0025d7a0 B _ZSt3cin@@GLIBCXX_3.4.31 0025d560 B _ZSt4cerr@@GLIBCXX_3.4 0025d560 B _ZSt4cerr@@GLIBCXX_3.4.31 0025d440 B _ZSt4clog@@GLIBCXX_3.4 0025d440 B _ZSt4clog@@GLIBCXX_3.4.31 0025d680 B _ZSt4cout@@GLIBCXX_3.4.31 0025d680 B _ZSt4cout@@GLIBCXX_3.4 But Florian's right, they're in the .a too.
[Bug c/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #2 from Andrew Cooper --- __builtin_frame_address() does appear to resolve the warning, but the knock-on effect for code generation is even worse than the asm() block. It forces a frame-pointer setup in all functions that use it (which is most functions in Xen), even leaf functions, and despite -fomit-frame-pointer, which in turn causes spilling of other registers now that %rbp isn't usable.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #8 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #7) > I think they're exported correctly with both versions: > > $ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c' > 0025d7a0 B _ZSt3cin@@GLIBCXX_3.4 > 0025d7a0 B _ZSt3cin@@GLIBCXX_3.4.31 > 0025d560 B _ZSt4cerr@@GLIBCXX_3.4 > 0025d560 B _ZSt4cerr@@GLIBCXX_3.4.31 > 0025d440 B _ZSt4clog@@GLIBCXX_3.4 > 0025d440 B _ZSt4clog@@GLIBCXX_3.4.31 > 0025d680 B _ZSt4cout@@GLIBCXX_3.4.31 > 0025d680 B _ZSt4cout@@GLIBCXX_3.4 Note, the GLIBCXX_3.4 ones should be @, not @@. > But Florian's right, they're in the .a too. Unfortunately we build libstdc++ objects just once because even libstdc++.a contains -fPIC code. So not sure how to arrange it to be libstdc++.so only.
[Bug c++/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Last reconfirmed||2023-02-28 Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |13.0 Keywords||ice-on-valid-code Known to fail||13.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #9 from Richard Biener --- (In reply to Florian Weimer from comment #6) > (In reply to Jonathan Wakely from comment #2) > > --- a/libstdc++-v3/src/c++98/globals_io.cc > > +++ b/libstdc++-v3/src/c++98/globals_io.cc > > @@ -43,6 +43,12 @@ > > // In macro form: > > // _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2) > > > > +#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION > > +# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31"))) > > +#else > > +# define SYMVER(sym) > > +#endif > > Is there anything that prevents these symbol versions getting added for > libstdc++.a? I think that could be problematic because a custom DSO > typically will not have a version node for GLIBCXX_3.4.31. Can we make everything hidden in libstdc++.a? If somebody builds a DSO with -static-libstdc++ then he very likely doesn't want to export libstdc++ symbols?
[Bug c/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #3 from Andreas Schwab --- Perhaps it works if you declare the register variable in file scope.
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #10 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #8) > Unfortunately we build libstdc++ objects just once because even libstdc++.a > contains -fPIC code. So not sure how to arrange it to be libstdc++.so only. We have a handful of objects which are built without --tag disable-shared in LTCXXCOMPILE, see src/Makefile.am So if we use that approach for globals_io.cc then we can check if _GLIBCXX_SHARED is defined to tell whether we're going into the .so or not.
[Bug target/108950] [11/12/13 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr'; error: type mismatch in 'widen_sum_expr') since r11-418-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108950
--- Comment #3 from Richard Biener ---
It's because we do
if (slp_node
&& !(!single_defuse_cycle
&& !lane_reduc_code_p
&& reduction_type != FOLD_LEFT_REDUCTION))
for (i = 0; i < (int) op.num_ops; i++)
if (!vect_maybe_update_slp_op_vectype (slp_op[i], vectype_op[i]))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
"incompatible vector types for invariants\n");
return false;
}
for the invariant lower precision op of the reduction. Arguably that's
not efficient. We're detecting a widen_sum from
n.0_1 = n;
_2 = (int) n.0_1;
m_lsm.19_13 = m;
[local count: 1073741824]:
# iter.6_8 = PHI <0(2), iter.6_9(5)>
# m_lsm.19_12 = PHI
# ivtmp_7 = PHI <2(2), ivtmp_18(5)>
_4 = _2 + m_lsm.19_12;
which is where we could fix this. I have a patch for the reduction code
for now.
[Bug c++/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||ice-checking --- Comment #3 from Jakub Jelinek --- --- gcc/cfgexpand.cc.jj 2023-02-21 11:44:48.479464567 +0100 +++ gcc/cfgexpand.cc2023-02-28 15:33:09.806750517 +0100 @@ -5365,6 +5365,10 @@ expand_debug_expr (tree exp) case VEC_WIDEN_MULT_ODD_EXPR: case VEC_WIDEN_LSHIFT_HI_EXPR: case VEC_WIDEN_LSHIFT_LO_EXPR: +case VEC_WIDEN_PLUS_HI_EXPR: +case VEC_WIDEN_PLUS_LO_EXPR: +case VEC_WIDEN_MINUS_HI_EXPR: +case VEC_WIDEN_MINUS_LO_EXPR: case VEC_PERM_EXPR: case VEC_DUPLICATE_EXPR: case VEC_SERIES_EXPR: certainly fixes this, not done yet with reduction though (so far at 300KB now). Haven't bisected yet, but if it reproduces only on the trunk, it would be latent since r11-5160-g9fc9573f9a5e9432e53c when those were introduced. Though, it is an checking ICE only, so doesn't reproduce with release branches by default (and does the right thing then, the ICE is solely about making sure that new trees which can be handled in expand_debug_expr are handled there).
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #11 from Marek Polacek --- No, because as Comment 9 says, there's no good way to suppress the warning. I'm currently leaning towards closing the BZ and suggesting adding a #pragma to disable the warning.
[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:ea718febab2a1f6e58806738abf70f1c73c6a308 commit r13-6376-gea718febab2a1f6e58806738abf70f1c73c6a308 Author: Marek Polacek Date: Thu Feb 23 17:54:47 2023 -0500 c++: ICE with constexpr variable template [PR107938] Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the CALL_EXPR is a function object. Q has a constexpr operator(), but since we're in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just a VAR_DECL; it hasn't been converted to Q::operator(&q, 0) yet. I propose to robustify check_address_or_pointer_of_packed_member. var-templ74.C has an XFAIL, subject to 107939. I noticed that our -Waddress-of-packed-member tests weren't testing member functions, added thus. (I was tempted to check FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.) PR c++/107938 gcc/c-family/ChangeLog: * c-warn.cc (check_address_or_pointer_of_packed_member): Check POINTER_TYPE_P. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ73.C: New test. * g++.dg/cpp1y/var-templ74.C: New test. * g++.dg/warn/Waddress-of-packed-member3.C: New test.
[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d918c3a221434521f90cc9b63d5d87f5129e9231 commit r13-6377-gd918c3a221434521f90cc9b63d5d87f5129e9231 Author: Marek Polacek Date: Tue Feb 21 19:13:59 2023 -0500 c++: variable template and targ deduction [PR108550] In this test, we get a bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. Then ensure_literal_type_for_constexpr_object thinks the object isn't literal and an error is reported. This is another case of the interaction between tf_partial and 'auto', where the auto was not reduced so the deduction failed. In more detail: we have Wrap1() in the code and we need to perform OR -> fn_type_unification. The targ list is incomplete, so we do tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type; fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain, NULL_TREE); where TREE_TYPE (fn) is struct integral_constant (void). Then we substitute the return type, which results in tsubsting is_pointer_v. is_pointer_v is a variable template with a placeholder type: template constexpr auto is_pointer_v = is_pointer::value; so we find ourselves in lookup_and_finish_template_variable. tf_partial is still set, so finish_template_variable -> instantiate_template -> tsubst won't reduce the level of auto. But then we do mark_used which eventually calls do_auto_deduction which clears tf_partial, because we want to replace the auto now. But we hadn't reduced auto's level so this fails. And since we're not in an immediate context, we emit a hard error. I suppose that when we reach lookup_and_finish_template_variable it's probably time to clear tf_partial. (I added an assert and our testsuite doesn't have a test whereby we get to lookup_and_finish_template_variable while tf_partial is still active.) PR c++/108550 gcc/cp/ChangeLog: * pt.cc (lookup_and_finish_template_variable): Clear tf_partial. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ70.C: New test. * g++.dg/cpp1y/var-templ71.C: New test. * g++.dg/cpp1y/var-templ72.C: New test.
[Bug c++/108550] [10/11/12 Regression] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 Marek Polacek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] the |the type 'const auto' of|type 'const auto' of |'constexpr' variable is not |'constexpr' variable is not |literal |literal --- Comment #10 from Marek Polacek --- Fixed on trunk so far.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Martin Liška changed: What|Removed |Added CC||rui314 at gmail dot com --- Comment #6 from Martin Liška --- > Plus, someone would have to reach out to the mold maintainer, as mold > doesn't seem to implement this special case. @Rui: ^^^
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 --- Comment #5 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:62ed1066196c81ab1fad13b2cc5ebbfe887138f9 commit r13-6378-g62ed1066196c81ab1fad13b2cc5ebbfe887138f9 Author: Gaius Mulley Date: Tue Feb 28 15:35:12 2023 + Fix build warnings noreturn M2RTS and fix calls to RegisterModule [PR108956] mc needs a fix to optionally suppress the generation of the noreturn attribute when building M2RTS. All the hand built C++ modules calling RegisterModule must supply the library name. These changes require the boot strap tools mc and pge to be rebuilt. gcc/m2/ChangeLog: PR modula2/108956 * Make-lang.in (m2/gm2-libs-boot/M2RTS.o): New specific rule to add the --suppress-noreturn option. * Make-maintainer.in (m2/gm2-ppg-boot/$(SRC_PREFIX)M2RTS.o): New specific rule to add the --suppress-noreturn option. (m2/gm2-pg-boot/$(SRC_PREFIX)M2RTS.o): New specific rule to add the --suppress-noreturn option. (m2/gm2-pg-boot/$(SRC_PREFIX)%.o): Add missing $(srcdir). (m2/gm2-pge-boot/$(SRC_PREFIX)M2RTS.o): New specific rule to add the --suppress-noreturn option. (m2/gm2-pge-boot/$(SRC_PREFIX)%.o): Add missing $(srcdir). * gm2-libs-ch/UnixArgs.cc (LIBNAME): New define. (_M2_UnixArgs_ctor): Add LIBNAME parameter to RegisterModule. * gm2-libs-ch/dtoa.cc (LIBNAME): New define. (_M2_dtoa_ctor): Add LIBNAME parameter to RegisterModule. * gm2-libs-ch/ldtoa.cc (LIBNAME): New define. (_M2_ldtoa_ctor): Add LIBNAME parameter to RegisterModule. * pge-boot/m2rts.h (M2RTS_RegisterModule): Add libname parameter. * gm2-libs-ch/m2rts.h (M2RTS_RegisterModule): Add libname parameter. * mc-boot-ch/GUnixArgs.cc (_M2_UnixArgs_ctor): Remove. * pge-boot/GUnixArgs.cc (LIBNAME): New define. (_M2_UnixArgs_ctor): Add LIBNAME parameter to RegisterModule. * gm2-libs/RTint.def (AttachVector): Rename parameter. * mc-boot/GDynamicStrings.c: Rebuilt. * mc-boot/GFIO.c: Rebuilt. * mc-boot/GIndexing.c: Rebuilt. * mc-boot/GM2EXCEPTION.c: Rebuilt. * mc-boot/GPushBackInput.c: Rebuilt. * mc-boot/GRTExceptions.c: Rebuilt. * mc-boot/GRTint.c: Rebuilt. * mc-boot/GRTint.h: Rebuilt. * mc-boot/GStdIO.c: Rebuilt. * mc-boot/GStringConvert.c: Rebuilt. * mc-boot/GSysStorage.c: Rebuilt. * mc-boot/Gdecl.c: Rebuilt. * mc-boot/Gkeyc.c: Rebuilt. * mc-boot/GmcComment.c: Rebuilt. * mc-boot/GmcComp.c: Rebuilt. * mc-boot/GmcDebug.c: Rebuilt. * mc-boot/GmcMetaError.c: Rebuilt. * mc-boot/GmcOptions.c: Rebuilt. * mc-boot/GmcOptions.h: Rebuilt. * mc-boot/GmcStack.c: Rebuilt. * mc-boot/GnameKey.c: Rebuilt. * mc-boot/GsymbolKey.c: Rebuilt. * mc/decl.mod:: Rebuilt. * mc/mcOptions.def: Rebuilt. * mc/mcOptions.mod:: Rebuilt. * pge-boot/GDynamicStrings.c: Rebuilt. * pge-boot/GFIO.c: Rebuilt. * pge-boot/GIndexing.c: Rebuilt. * pge-boot/GM2EXCEPTION.c: Rebuilt. * pge-boot/GM2RTS.c: Rebuilt. * pge-boot/GNameKey.c: Rebuilt. * pge-boot/GPushBackInput.c: Rebuilt. * pge-boot/GRTExceptions.c: Rebuilt. * pge-boot/GStdIO.c: Rebuilt. * pge-boot/GSymbolKey.c: Rebuilt. * pge-boot/GSysStorage.c: Rebuilt. Signed-off-by: Gaius Mulley
[Bug c++/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #4 from Jakub Jelinek ---
Somewhat reduced for -O2 -g:
template
struct A {
using T = unsigned short;
static constexpr int a = N;
};
template
struct B { using type = A; };
struct C {
static constexpr int N = 16 / sizeof (short);
using type = B::type;
};
template using D = C::type;
template using E = typename U::T;
template struct F {
unsigned short r[16 / sizeof(short)];
};
template
F, U::a> baz (U);
template
using G = decltype(baz (U ()));
template
G qux (U, T);
template
F
boo (F b)
{
F a;
for (int i = 0; i < N; ++i)
a.r[i] = a.r[i] + b.r[i] < T(-1) ? a.r[i] + b.r[i] : T(-1);
return a;
}
void corge (G>);
template
void
freddy (U, V v, V)
{
corge (v);
}
template
struct H {
static void garply (int, int) { D d; V() (int(), d); }
};
struct I;
template
struct J {
template
void operator () (T) { int m = 1; H::garply (1, m); }
};
struct K {
void operator () (short t) { J() (t); }
};
struct I {
template
void
operator () (T, U d)
{
auto a = qux (d, T()), b = qux (d, 0);
F c = boo (b);
freddy (d, c, a);
}
};
void
test ()
{
K k;
k (short ());
}
[Bug c/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 Andrew Cooper changed: What|Removed |Added Component|analyzer|c --- Comment #4 from Andrew Cooper --- (In reply to Andreas Schwab from comment #3) > Perhaps it works if you declare the register variable in file scope. Huh. I honestly expected that not to compile, but it appears to, and it appears to work. There is minor perturbation in the build, but as far as I can see, it's just slightly different register/instruction scheduling. Why does being at global scope change the diagnostic?
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Segher Boessenkool changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Segher Boessenkool --- This is not a special case at all.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #8 from Segher Boessenkool --- To expand a bit: st_other with value 1 was reserved before, and now it isn't anymore. Any tool that silently ignores the "special case" of reserved values will not work correctly (it might sometimes do what is wanted though). This is true everywhere always.
[Bug tree-optimization/108970] New: [13 Regression] ICE in vect_do_peeling, at tree-vect-loop-manip.cc:2971, or ICE in dump_printf_loc, at dumpfile.cc:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
Bug ID: 108970
Summary: [13 Regression] ICE in vect_do_peeling, at
tree-vect-loop-manip.cc:2971, or ICE in
dump_printf_loc, at dumpfile.cc:1359
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
1. gcc 13.0.1 20230226 snapshot (g:e6d39f68d03c46637ca6e1bede3d28eae6278df3)
ICEs when compiling the following testcase w/ -O1 -ftree-loop-vectorize
-fsave-optimization-record -fno-tree-dce -fno-tree-scev-cprop:
int m;
__attribute__ ((noinline, returns_twice)) void
empty (void)
{
}
void
foo (void)
{
while (m < 1)
{
empty ();
++m;
}
}
% gcc-13 -O1 -ftree-loop-vectorize -fsave-optimization-record -fno-tree-dce
-fno-tree-scev-cprop -c ionf2mqq.c
during GIMPLE pass: vect
ionf2mqq.c: In function 'foo':
ionf2mqq.c:9:1: internal compiler error: in vect_do_peeling, at
tree-vect-loop-manip.cc:2971
9 | foo (void)
| ^~~
0x119566f vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vect-loop-manip.cc:2971
0x1187e99 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vect-loop.cc:10807
0x11c6ca0 vect_transform_loops
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1007
0x11c72de try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1153
0x11c72de try_vectorize_loop
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1183
0x11c7694 execute
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1299
2. Omitting -fsave-optimization-record yields the following instead:
% gcc-13 -O1 -ftree-loop-vectorize -fno-tree-dce -fno-tree-scev-cprop -c
ionf2mqq.c
during GIMPLE pass: vect
ionf2mqq.c: In function 'foo':
ionf2mqq.c:9:1: internal compiler error: in dump_printf_loc, at
dumpfile.cc:1359
9 | foo (void)
| ^~~
0x6c16b2 dump_printf_loc(dump_metadata_t const&, dump_user_location_t const&,
char const*, ...)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/dumpfile.cc:1359
0x119565b vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vect-loop-manip.cc:2969
0x1187e99 vect_transform_loop(_loop_vec_info*, gimple*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vect-loop.cc:10807
0x11c6ca0 vect_transform_loops
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1007
0x11c72de try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1153
0x11c72de try_vectorize_loop
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1183
0x11c7694 execute
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-vectorizer.cc:1299
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 Christophe Lyon changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- I can see that aarch64_function_arg_alignment has: if (!AGGREGATE_TYPE_P (type)) return TYPE_ALIGN (TYPE_MAIN_VARIANT (type)); which returns 512 with the testcase from comment #0 type is (TYPE_MAIN_VARIANT(type) is the same): unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x776222a0 precision:32 pointer_to_this > sizes-gimplified public unsigned DI size constant 64> unit-size constant 8> user align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77622888 attributes value >>>
[Bug tree-optimization/108970] [13 Regression] ICE in vect_do_peeling, at tree-vect-loop-manip.cc:2971, or ICE in dump_printf_loc, at dumpfile.cc:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #33 from H.J. Lu --- (In reply to Uroš Bizjak from comment #20) > (In reply to Jakub Jelinek from comment #16) > > > More questionable is the #Z case, where Table 8-11 just talks about > > Divide or reverse divide operation Returns an ∞ signed with the exclusive > > OR of the > > with a 0 divisor. sign of the two operands to the > > destination operand. > > but FPREM does division too, so I hope it is covered too (but not listed > > explicitly). > > FYI, the table 3-30 (and 3-31) is wrong. Executing fprem when st(0) == 1.0 > and st(1) == 0.0 results in IA exception, not Z exception. Thanks for bringing it up. It will be fixed in the next revision for Intel SDM.
[Bug debug/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967 --- Comment #5 from Jakub Jelinek --- Created attachment 54557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54557&action=edit gcc13-pr108967.patch Full untested patch.
[Bug c/108964] Attribute target should be implemented for C backend (not only c++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108964 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|powerpc |powerpc64le Last reconfirmed||2023-02-28 Ever confirmed|0 |1 --- Comment #7 from Segher Boessenkool --- The mystery is not where the permutations came from: they were added during expand to make correct code, just like many unnecessary register moves are added at that time. This is normal, and even good in many ways. The question is why they weren't optimised better. This is either due to some bug, or this is an enhancement request.
[Bug lto/108971] New: [13 Regression] ICE in tree_profiling, at tree-profile.cc:724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971
Bug ID: 108971
Summary: [13 Regression] ICE in tree_profiling, at
tree-profile.cc:724
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, lto
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
gcc 13.0.1 20230226 snapshot (g:e6d39f68d03c46637ca6e1bede3d28eae6278df3) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C, w/ -std=c++2a
-fbranch-probabilities -flto -fno-inline:
template
concept C1 = __is_same_as(T, int);
template
concept IsNotTiny = !__is_same_as(T, char);
void
foo ()
{
auto g = [] requires IsNotTiny(T t) -> T
requires IsNotTiny { return t; };
[](auto t) requires true { return t; }(5);
[](C1 auto t) { return t; }(5);
auto a0 = [](IsNotTiny auto a) { return [](auto b){ return b; }; };
auto a1 = a0(1);
}
% g++-13 -std=c++2a -fbranch-probabilities -flto -fno-inline -c sanpvd3f.C
sanpvd3f.C:16:13: error: mangling of 'foo():: [with auto:3 =
int]' as '_ZZ3foovENKUlT_E1_clIiEEDaS_' conflicts with a previous mangle
16 | auto a0 = [](IsNotTiny auto a) { return [](auto b){ return b; }; };
| ^
sanpvd3f.C:14:3: note: previous mangling 'int
foo()_ZZ3foovENKUlT_E1_clIiEEDaS_(int) const'
14 | [](C1 auto t) { return t; }(5);
| ^
sanpvd3f.C:16:13: note: a later '-fabi-version=' (or =0) avoids this error with
a change in mangling
16 | auto a0 = [](IsNotTiny auto a) { return [](auto b){ return b; }; };
| ^
during IPA pass: profile
sanpvd3f.C:18:1: internal compiler error: in tree_profiling, at
tree-profile.cc:724
18 | }
| ^
0x859ae9 tree_profiling
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-profile.cc:724
0x859ae9 execute
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree-profile.cc:888
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 --- Comment #5 from Jonathan Wakely --- (In reply to G. Steinmetz from comment #0) > typedef __INT8_TYPE__ int8_t; > typedef __INT32_TYPE__ int32_t; > extern void* memchr (const void*, int, long); For the record, the signature above is wrong (the third parameter should be size_t not long), and that's what caused the ICE. (So I think this should really be ice-on-invalid-code since it has a bad declaration of memchr).
[Bug c++/108972] New: ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in compare_lambda_template_head, at cp/lambda.cc:1551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
Bug ID: 108972
Summary: ICE: tree check: expected tree that contains 'decl
common' structure, have 'error_mark' in
compare_lambda_template_head, at cp/lambda.cc:1551
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, lto
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org, unassigned at gcc dot gnu.org
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #108971 +++
gcc 13.0.1 20230226 snapshot (g:e6d39f68d03c46637ca6e1bede3d28eae6278df3) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C, w/ -fbranch-probabilities -flto
-fno-inline:
template
concept C1 = __is_same_as(T, int);
template
concept IsNotTiny = !__is_same_as(T, char);
void
foo ()
{
auto g = [] requires IsNotTiny(T t) -> T
requires IsNotTiny { return t; };
[](auto t) requires true { return t; }(5);
[](C1 auto t) { return t; }(5);
auto a0 = [](IsNotTiny auto a) { return [](auto b){ return b; }; };
auto a1 = a0(1);
}
% g++-13 -fbranch-probabilities -flto -fno-inline -c sanpvd3f.C
sanpvd3f.C:2:1: error: 'concept' does not name a type; did you mean 'const'?
2 | concept C1 = __is_same_as(T, int);
| ^~~
| const
sanpvd3f.C:2:1: note: 'concept' only available with '-std=c++20' or
'-fconcepts'
sanpvd3f.C:5:1: error: 'concept' does not name a type; did you mean 'const'?
5 | concept IsNotTiny = !__is_same_as(T, char);
| ^~~
| const
sanpvd3f.C:5:1: note: 'concept' only available with '-std=c++20' or
'-fconcepts'
sanpvd3f.C: In function 'void foo()':
sanpvd3f.C:10:15: error: 'C1' has not been declared
10 | auto g = [] requires IsNotTiny(T t) -> T
| ^~
sanpvd3f.C:10:21: error: 'requires' only available with '-std=c++20' or
'-fconcepts'
10 | auto g = [] requires IsNotTiny(T t) -> T
| ^~~~
sanpvd3f.C:10:30: error: 'IsNotTiny' was not declared in this scope
10 | auto g = [] requires IsNotTiny(T t) -> T
| ^
sanpvd3f.C:10:40: error: 'T' was not declared in this scope
10 | auto g = [] requires IsNotTiny(T t) -> T
|^
sanpvd3f.C:10:43: error: 'T' was not declared in this scope
10 | auto g = [] requires IsNotTiny(T t) -> T
| ^
sanpvd3f.C:10:44: error: expected ')' before 't'
10 | auto g = [] requires IsNotTiny(T t) -> T
| ~ ^~
|)
sanpvd3f.C: In lambda function:
sanpvd3f.C:11:50: error: expected '{' before ';' token
11 | requires IsNotTiny { return t; };
| ^
sanpvd3f.C: In function 'void foo()':
sanpvd3f.C:13:14: error: 'requires' only available with '-std=c++20' or
'-fconcepts'
13 | [](auto t) requires true { return t; }(5);
| ^~~~
sanpvd3f.C:13:23: internal compiler error: tree check: expected tree that
contains 'decl common' structure, have 'error_mark' in
compare_lambda_template_head, at cp/lambda.cc:1551
13 | [](auto t) requires true { return t; }(5);
| ^~~~
0x896ef7 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree.cc:9083
0x70171c contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/tree.h:3644
0x70171c compare_lambda_template_head
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/lambda.cc:1551
0xa6a86c compare_lambda_sig
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/lambda.cc:1598
0xa6a86c record_lambda_scope_sig_discriminator(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/lambda.cc:1656
0xb234b8 cp_parser_lambda_declarator_opt
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/parser.cc:11774
0xb05f86 cp_parser_lambda_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/parser.cc:11142
0xb06d63 cp_parser_primary_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/parser.cc:5826
0xb095e6 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230226/work/gcc-13-20230226/gcc/cp/parser.cc:
0xaf1454 cp_parser_binary_expression
[Bug c++/108966] Inheriting consteval constructor makes it constexpr in the derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 104490 ***
[Bug c++/104490] Cannot inherit consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490 Patrick Palka changed: What|Removed |Added CC||g...@arne-mertz.de --- Comment #5 from Patrick Palka --- *** Bug 108966 has been marked as a duplicate of this bug. ***
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #14 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:afe6cea4489846aa8585f3c045d16cdaa08cc6cd commit r13-6379-gafe6cea4489846aa8585f3c045d16cdaa08cc6cd Author: Qing Zhao Date: Tue Feb 28 17:11:05 2023 + Fixing PR107411 This is a bug in tree-ssa-uninit.cc. When doing the following: /* Ignore the call to .DEFERRED_INIT that define the original var itself as the following case: temp = .DEFERRED_INIT (4, 2, âalt_reloc"); alt_reloc = temp; In order to avoid generating warning for the fake usage at alt_reloc = temp. */ We need to compare the var name inside the .DEFERRED_INIT call (the 3rd argument) and the name for the LHS variable. if they are the same, we will NOT report the warning. There is one issue when we get the name for the LHS variable. when the variable doesn't have a DECL_NAME (it's not a user declared variable, which is the case for this bug): _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); D.2389 = _1; The current checking just ignores this case, and still report the warning. The fix is very simple, when getting the name for the LHS variable, we should consider this case and come up with the name the same way as we construct the 3rd argument for the call to .DEFERRED_INIT (please refer to the routine "gimple_add_init_for_auto_var") PR middle-end/107411 gcc/ChangeLog: PR middle-end/107411 * gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to replace xasprintf. * tree-ssa-uninit.cc (warn_uninit): Handle the case when the LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME. gcc/testsuite/ChangeLog: PR middle-end/107411 * g++.dg/pr107411.C: New test.
[Bug testsuite/108973] New: Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Bug ID: 108973
Summary: Sufficiently narrow terminal window causes selftest
failure
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Running the selftests in a sufficiently-narrow terminal window (in my case
$COLUMNS < 42) causes the following selftest failure:
$ echo $COLUMNS
41
$ ./xgcc -B . -c -xc /dev/null
-fself-test=$HOME/toolchain/src/gcc/gcc/testsuite/selftests
/home/alecop01/toolchain/src/gcc/gcc/diagnostic-show-locus.cc:4452:
test_add_location_if_nearby: FAIL: ASSERT_STREQ (" struct same_line { double x;
double y; ;\n" " ~^\n", pp_formatted_text
(dc.printer))
val1=" struct same_line { double x; double y; ;
~^
"
val2=" truct same_line { double x; double y; ;
~^
"
cc1: internal compiler error: in fail_formatted, at selftest.cc:63
0x2b02675 selftest::fail_formatted(selftest::location const&, char const*, ...)
/home/alecop01/toolchain/src/gcc/gcc/selftest.cc:63
0x2b02764 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
/home/alecop01/toolchain/src/gcc/gcc/selftest.cc:92
0x2b24547 test_add_location_if_nearby
/home/alecop01/toolchain/src/gcc/gcc/diagnostic-show-locus.cc:4450
0x2b51737 selftest::for_each_line_table_case(void (*)(selftest::line_table_case
const&))
/home/alecop01/toolchain/src/gcc/gcc/input.cc:3899
0x2b2bf52 selftest::diagnostic_show_locus_cc_tests()
/home/alecop01/toolchain/src/gcc/gcc/diagnostic-show-locus.cc:5706
0x29c8f24 selftest::run_tests()
/home/alecop01/toolchain/src/gcc/gcc/selftest-run-tests.cc:96
0x15d19c4 toplev::run_self_tests()
/home/alecop01/toolchain/src/gcc/gcc/toplev.cc:2184
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from qinzhao at gcc dot gnu.org --- resolved in GCC13
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 107411, which changed state. Bug 107411 Summary: trivial-auto-var-init=zero invalid uninitialized variable warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #5 from David Malcolm ---
Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
Am I right in understanding that:
register unsigned long sp asm("rsp");
is intended as a way to read the %rsp register?
If so, I think the analyzer might be failing to grok that idiom.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #6 from Andrew Cooper ---
(In reply to David Malcolm from comment #5)
> Minimal reproducer: https://godbolt.org/z/E6EEY1WT6
>
> Am I right in understanding that:
> register unsigned long sp asm("rsp");
> is intended as a way to read the %rsp register?
Ultimately, yes.
More generally, this just creates a way to access the specific register.
It is the only way for example to create an asm constraint on e.g. %r8, so the
following is common to see for MSABI:
register unsigned long param asm ("%r8");
param = 4;
asm ("tdcall/whatever"
: "+r" (param) ...);
(Example here is from Intel's new TDX technology, but the actual asm
instruction isn't important.)
[Bug c++/108974] New: std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Bug ID: 108974
Summary: std::barrier except completion function which is not
manifestly noexcept
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
std::barrier> b{1, [](){}};
is accepted by gcc (and clang).
However, it fails on MSVC - as I think it should - since std::function's call
operator isn't manifestly noexcept.
https://godbolt.org/z/7vfoa1qhn
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #1 from Andrew Pinski --- Created attachment 54558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54558&action=edit Full testcase
[Bug c++/108848] [10/11/12/13 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d3d205ab440886164b6de2be2a2efa10cac95b66 commit r13-6380-gd3d205ab440886164b6de2be2a2efa10cac95b66 Author: Patrick Palka Date: Tue Feb 28 15:05:30 2023 -0500 c++: non-dependent variable template-id [PR108848] Here we're treating deeming the non-dependent variable template-id tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR an empty type, which causes the call to finish_template_variable from finish_id_expression_1 to be unreachable at template parse time. Thus we're led into thinking tag.var refers to a dependent name. This patch fixes this by making finish_id_expression_1 instantiate a variable template-id as long as it's not dependent according to the dependence test in lookup_and_finish_template_variable rather than according to type_dependent_expression_p. PR c++/108848 gcc/cp/ChangeLog: * pt.cc (finish_template_variable): Move dependence check to here from ... (lookup_and_finish_template_variable): ... here. * semantics.cc (finish_id_expression_1): Call finish_template_variable sooner, before (and regardless of) the type_dependent_expression_p test. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/noexcept1.C: Don't expect a bogus "different exception specifier" error. Expect a separate "not usable in a constant expression" error. * g++.dg/cpp1y/var-templ75.C: New test. * g++.dg/cpp1y/var-templ76.C: New test.
[Bug c++/108848] [10/11/12 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848 Patrick Palka changed: What|Removed |Added Known to work||13.0 Known to fail|13.0| Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |template keyword|template keyword |incorreclty required to |incorreclty required to |access template class |access template class |static member of|static member of |non-dependent expression|non-dependent expression |using member syntax in |using member syntax in |dependent context |dependent context --- Comment #4 from Patrick Palka --- Fixed for GCC 13 so far
[Bug fortran/106946] [10/11/12/13 Regression] ICE in resolve_component, at fortran/resolve.cc:14726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106946
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Minor remark: there's a memleak in gfc_find_derived_vtab that is plugged by
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index ae653e74437..3dd2d9db70b 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -2344,6 +2344,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
vtab->attr.vtab = 1;
vtab->attr.access = ACCESS_PUBLIC;
gfc_set_sym_referenced (vtab);
+ free (name);
name = xasprintf ("__vtype_%s", tname);
gfc_find_symbol (name, ns, 0, &vtype);
[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #3 from Marek Polacek ---
// PR c++/106259
// { dg-do compile { target c++11 } }
template struct A {
template
struct W { };
};
template<>
struct A {
template
class W { };
};
void
g ()
{
struct A::W w1; // warn
struct A::W w2; // dont warn
class A::W w3; // dont warn
class A::W w4; // warn
}
[Bug c++/108975] New: Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Bug ID: 108975
Summary: Internal compiler error on constexpr variable used as
nontype template
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: samuelpmish at gmail dot com
Target Milestone: ---
Hi,
I'm running into an internal compiler error with g++ (12.1.0):
internal compiler error: in lookup_template_class_1, at cp/pt.cc:10114
[build] 120 | using derivative_type =
decltype(domain_integral::get_derivative_type(qf,
state_type{}));
[build] |
^~~
[build] 0x662042 lookup_template_class_1
[build] ../../src/gcc/cp/pt.cc:10114
[build] 0x81c004 lookup_template_class(tree_node*, tree_node*, tree_node*,
tree_node*, int, int)
[build] ../../src/gcc/cp/pt.cc:10353
[build] 0x81c004 tsubst_aggr_type
[build] ../../src/gcc/cp/pt.cc:13747
[build] 0x80e549 tsubst_aggr_type
[build] ../../src/gcc/cp/pt.cc:17421
[build] 0x80e549 tsubst_copy
[build] ../../src/gcc/cp/pt.cc:16928
[build] 0x80fc58 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../src/gcc/cp/pt.cc:21050
[build] 0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../src/gcc/cp/pt.cc:19491
[build] 0x81cfb2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../src/gcc/cp/pt.cc:18462
[build] 0x81cfb2 tsubst_decl
[build] ../../src/gcc/cp/pt.cc:15004
[build] 0x80e92b tsubst_copy
[build] ../../src/gcc/cp/pt.cc:17000
[build] 0x80f4e1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../src/gcc/cp/pt.cc:21265
[build] 0x80fe8d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../src/gcc/cp/pt.cc:20117
[build] 0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../src/gcc/cp/pt.cc:19491
[build] 0x825bad tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
[build] ../../src/gcc/cp/pt.cc:13517
[build] 0x8108fe tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../src/gcc/cp/pt.cc:20055
[build] 0x80f865 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../src/gcc/cp/pt.cc:20676
[build] 0x818c01 tsubst(tree_node*, tree_node*, int, tree_node*)
[build] ../../src/gcc/cp/pt.cc:16315
[build] 0x81c344 tsubst_decl
[build] ../../src/gcc/cp/pt.cc:14952
[build] 0x8226bb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../src/gcc/cp/pt.cc:18590
[build] 0x821632 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../src/gcc/cp/pt.cc:18462
g++ (11.3.0) also fails in a similar way:
internal compiler error: in lookup_template_class_1, at cp/pt.c:10093
[build] 120 | using derivative_type =
decltype(domain_integral::get_derivative_type(qf,
state_type{}));
[build] |
^~~
[build] 0x7fc84da29d8f __libc_start_call_main
[build] ../sysdeps/nptl/libc_start_call_main.h:58
[build] 0x7fc84da29e3f __libc_start_main_impl
[build] ../csu/libc-start.c:392
but g++ (10.4.0) and clang (14.0.0) compile the same code without any issues.
-
The line of code it referred to before the backtrace is something like:
constexpr int dim = dimension_of(geom);
[&](auto index) {
...
using derivative_type =
decltype(domain_integral::get_derivative_type(qf,
state_type{}));
...
}
If I make `dim` static in addition to constexpr, then the internal compiler
error disappears. I've tried for a bit to come up with a smaller example that
reproduces this issue, but wasn't able to find one.
The full compilation line is (after removing some long include directory flags)
/usr/bin/g++-12 -DAXOM_DEBUG -DGTEST_HAS_DEATH_TEST=0 -Wall -Wextra -pthread
-freport-bug -Werror -Wshadow -Wdouble-promotion -Wconversion -Wundef
-Wnull-dereference -Wold-style-cast -g -fPIE -fopenmp -Wno-class-memaccess
-DCONDUIT_RELAY_IO_MPI_ENABLED -DCONDUIT_BLUEPRINT_MPI_ENABLED -std=c++17 -o
file.o -c file.cpp
Following the guidance in README.Bugs, I also compiled with -save-temps to
produce a .ii file, but it is too large to attach here, so I'll include a
dropbox link to it: https://www.dropbox.com/s/slrf8r500vargd5/file.ii?dl=0
I'm new to submitting bugs to gcc/g++, so if there's any more information I can
provide please let me know.
Sam
[Bug c++/108975] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #1 from Andrew Pinski --- >but it is too large to attach here, You can use bzip2 or zip to compress it and attach that.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #6 from Costas Argyris --- Created attachment 54559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54559&action=edit Integrate UTF-8 manifest into gcc's build process for mingw host This builds fine and the resource object does get linked into the final gcc.exe, however, it still doesn't work - still breaks when fed with a Unicode source path.
[Bug fortran/108452] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108452 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-02-28 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #1 from anlauf at gcc dot gnu.org --- Replacing use m, u => g, v => g by use m, only: u => g, v => g makes the code compile and gives an apparently sane dump.
[Bug c++/108975] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #2 from Sam Mish --- Does the dropbox link to the .ii file not work for you, Andrew?
[Bug c++/108975] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #3 from Andrew Pinski --- (In reply to Sam Mish from comment #2) > Does the dropbox link to the .ii file not work for you, Andrew? It does but I was just explaining how we are ok with compressed files in many cases.
