[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769 --- Comment #3 from Andrew Pinski --- (In reply to Giuseppe D'Angelo from comment #2) > > * rejects the code due to the default constructor being invalid. > > That would be Clang? Yes sorry I forgot to mark it as such.
[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769 --- Comment #1 from Andrew Pinski --- MSVC (and EDG) return true for is_default_constructible_v> . Which is different from clang. So in summary we have the following 3 behaviors: * accepts the code and is_default_constructible_v> value is true: EDG/MSVC * accepts the code and is_default_constructible_v> value is false: GCC * rejects the code due to the default constructor being invalid.
[Bug c++/116770] Diagnostic 'explicit qualification in declaration of' could be clearer when explicit namespace qualifier matches the open namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64267 --- Comment #4 from Andrew Pinski --- (In reply to Marek Polacek from comment #3) > (In reply to Andrew Pinski from comment #2) > > DR482 > > We have bug 64267 for that. Right I was just looking that up :).
[Bug c++/116770] Diagnostic 'explicit qualification in declaration of' could be clearer when explicit namespace qualifier matches the open namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770 --- Comment #2 from Andrew Pinski --- DR482
[Bug c++/116771] Missing suggestion on mispelled class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116771 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-18 Severity|normal |enhancement Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 --- Comment #5 from Andrew Pinski --- (In reply to Alisa Sireneva from comment #4) > With the new reproducer, this doesn't work on 11.4 Oh right I must have missed that when I moved over to the new testcase.
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- And with -pedantic-errors we get: ``` :6:21: error: ISO C forbids qualified function types [-Wpedantic] 6 | static const MyFunc my_func; | ^~~ ``` So there is nothing to fix here. As the extension is very well documented (though only again since GCC 14 due to it being mistakely removed, see PR 107942 for details on that one) and this extension has existed since at least 2.95.3 (most likely earlier before attributes were around).
[Bug c/116767] C const function pointer no code generated (or optimized out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767 --- Comment #5 from Andrew Pinski --- This extension is documented: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Const-and-Volatile-Functions.html
[Bug c/107942] [11/12/13/14 Regression] Documentation of the volatile style for noreturn is gone and const style for const attribute is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107942 Andrew Pinski changed: What|Removed |Added Target Milestone|11.5|14.0
[Bug tree-optimization/116766] Missed loop vectorization case with gather/scatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116766 Andrew Pinski changed: What|Removed |Added Blocks||53947 Severity|normal |enhancement See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104368 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
--- Comment #3 from Andrew Pinski ---
Here is a testcase which does NOT need -mavx to fail and fails on aarch64 too:
```
#define numwords 2
typedef struct {
unsigned words[numwords];
} Child;
typedef struct {
Child child;
} Parent;
Parent my_or(Parent x, const Parent *y) {
const Child *y_child = &y->child;
for (int i = 0; i < numwords; i++) {
x.child.words[i] |= y_child->words[i];
}
return x;
}
int main() {
Parent bs[4];
__builtin_memset(bs, 0, sizeof(bs));
bs[0].child.words[0] = 1;
for (int i = 1; i <= 3; i++) {
bs[i] = my_or(bs[i], &bs[i - 1]);
}
return bs[2].child.words[0];
}
```
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-18 Known to fail||12.1.0 Known to work||11.4.0 Keywords||needs-bisection Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |12.5 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/116768] [12/13/14/15 regression] Strict aliasing breaks autovectorization with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768 --- Comment #1 from Andrew Pinski --- -fno-vect-cost-model hides it
[Bug c/116764] SIGSEGV in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116764 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Huh? a is a null pointer so writing to it will cause this behavior.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #42 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #41)
> I still can't reproduce it even with a 14.2.0 worktree nested under the main
> repo dir.
>
> What does this show when run in the build dir?
>
> grep -w VPATH
> x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
apinski@xeond:~/src/tt1/gcc/worktrees/14.2.0/tt1/tt1$ grep -w VPATH
x86_64-pc-linux-gnu/{.,32}/libstdc++-v3/src/libbacktrace/Makefile
x86_64-pc-linux-gnu/./libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace
x86_64-pc-linux-gnu/32/libstdc++-v3/src/libbacktrace/Makefile:VPATH =
/home/apinski/src/tt1/gcc/worktrees/14.2.0/libstdc++-v3/src/libbacktrace
[Bug tree-optimization/116747] [12/13/14/15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 Andrew Pinski changed: What|Removed |Added Target Milestone|15.0|12.5 --- Comment #13 from Andrew Pinski --- This fixes the ICE but I am not 100% sure if this is the right approach or should we change how write after write checks are done. diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc index d43832b390b..6da60771702 100644 --- a/gcc/tree-ssa-phiopt.cc +++ b/gcc/tree-ssa-phiopt.cc @@ -3451,7 +3451,10 @@ cond_if_else_store_replacement_1 (basic_block then_bb, basic_block else_bb, || else_assign == NULL || !gimple_assign_single_p (else_assign) || gimple_clobber_p (else_assign) - || gimple_has_volatile_ops (else_assign)) + || gimple_has_volatile_ops (else_assign) + /* If there was undefined behavior, else_assign might +have been removed already. */ + || !gimple_bb (else_assign)) return false; lhs = gimple_assign_lhs (then_assign);
[Bug tree-optimization/116747] [12/13/14/15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Summary|[15 Regression] ICE on |[12/13/14/15 Regression]
|valid code at -O3 on|ICE on valid code at -O3 on
|x86_64-linux-gnu: |x86_64-linux-gnu:
|Segmentation fault |Segmentation fault
Known to work||8.5.0
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Known to fail||9.1.0
--- Comment #12 from Andrew Pinski ---
decl_refs_may_alias_p (ref1=0x779edf88, base1=0x77810e10, offset1=...,
max_size1=..., size1=..., ref2=0x779eddc8, base2=0x77810e10,
offset2=..., max_size2=..., size2=...) at
/home/apinski/src/upstream-gcc-isel/gcc/gcc/tree-ssa-alias.cc:2051
2051 gcc_checking_assert (DECL_P (base1) && DECL_P (base2));
(gdb) next
2054 if (compare_base_decls (base1, base2) == 0)
(gdb)
2059 if (!ranges_maybe_overlap_p (offset1, max_size1, offset2, max_size2))
(gdb)
2060return false;
(gdb) p offset1
$11 = {coeffs = {32}}
(gdb) p max_size1
$12 = {coeffs = {0}}
(gdb) p offset2
$13 = {coeffs = {32}}
(gdb) p max_size2
$14 = {coeffs = {0}}
Reduced testcase that fails in GCC 14 and the way back to GCC 9.1.0 even.
Compile with `-fno-tree-fre -fno-tree-dse -O3` .
```
int array1[1];
int array2[1];
int f(int a, int b, int c)
{
if (b < 1) __builtin_unreachable();
if (a)
{
array1[b] = c;
array1[b] = c;
}
else
{
array1[b] = c;
}
}
int f1(int a, unsigned short b1, int c)
{
int b = b1;
b++;
if (a)
{
array1[b] = c;
array1[b] = c;
}
else
{
array1[b] = c;
}
}
```
This code (and the original one) is undefined due to accessing out side of the
array bounds.
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-18 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- issue 1 is only an issue with std::numeric_limits::min() and gets an undefined sanitizer hit too. /opt/compiler-explorer/gcc-trunk-20240917/include/c++/15.0.0/bits/chrono.h:602:11: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself
[Bug libstdc++/116755] format and print functions prepend extra minus sign for min value of chrono duration type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755 --- Comment #3 from Andrew Pinski --- Issue 2: std println treats duration(54) as char '6' d2 "6s" I think issue 2 is not an bug and it happens with libc++ too. issue 1 does seem like a bug though.
[Bug middle-end/116753] [13/14/15 Regression] GCC trunk (-O3) can't fold a loop into a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116753 Andrew Pinski changed: What|Removed |Added Summary|[regression from GCC 12.4] |[13/14/15 Regression] GCC |GCC trunk (-O3) can't fold |trunk (-O3) can't fold a |a loop into a constant |loop into a constant Known to fail||13.1.0 Ever confirmed|0 |1 Keywords||needs-bisection Known to work||12.4.0 Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-17 Target Milestone|--- |12.5 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #11 from Andrew Pinski --- Note if I have refs_may_alias_p return true always, the code to check to see if there was a write after write dependent store happening works and cselim does nothing here.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 Andrew Pinski changed: What|Removed |Added Keywords||alias Status|ASSIGNED|NEW --- Comment #10 from Andrew Pinski --- Since it is an aliasing over to richi I think. phiopt/cselim looks to be doing the correct thing and asking the correct questions too.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #9 from Andrew Pinski --- Looks like dr_may_alias_p is returning the wrong result.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #8 from Andrew Pinski --- 1: dump_data_dependence_relation(stdout, ddr) = (Data Dep: #(Data Ref: # bb: 12 # stmt: d[e.0_43] = _17; # ref: d[e.0_43]; # base_object: d[e.0_43]; #) #(Data Ref: # bb: 12 # stmt: d[e.0_43] = _41; # ref: d[e.0_43]; # base_object: d[e.0_43]; #) (no dependence) ) That is wrong. This is a write after write dependency. The question now becomes why DDR_ARE_DEPENDENT is chrec_known. Even though it is obvious. So the bug is not in phiopt at all it seems but tree-data-ref.cc.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #7 from Andrew Pinski --- So reading the code: Check that there are no read-after-write or write-after-write dependencies in THEN_BB. /* Check that there are no read-after-write or write-after-write dependencies in ELSE_BB. */ Should have caught this case but for some reason it is not.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Andrew Pinski --- I am going to fix this. I am still trying to understand datarefs code part and why it just happens to work with the gimple testcase.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #5 from Andrew Pinski --- So a gimple testcase does not fail.
[Bug middle-end/116750] New documentation section about how on produce reproducible objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750 --- Comment #6 from Andrew Pinski --- (In reply to Sam James from comment #5) > and maybe the obvious stuff too like not using __TIME__/__DATE__, the map > source options, ... Yep. It might make sense to list some of the GNU linker options that might influence this too but we definitely to point out those only applies to the GNU linker and that other linkers might have other options too. Like build-id could be used to make sure they produce the same binary, etc.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > Actually started with r15-1163-g818e760528d436ea8f6c28ef620e2bb82d456ea1 Oh ok, I figured it was a DSE change which exposed it. I am still trying to figure out how to get a gimple testcase, a C testcase with `-fno-tree-dse -fno-tree-fre -O3` does not reproduce the issue though. But maybe I am testing it incorrectly. Maybe I need -fno-tree-vectorizer too.
[Bug middle-end/116750] New documentation section about how on produce reproducible objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750 Andrew Pinski changed: What|Removed |Added Summary|--coverage generates random |New documentation section |.data.rel |about how on produce ||reproducible objects Severity|normal |enhancement Component|c++ |middle-end Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- Confirmed. This is a general issue, just happens that coverage is more likely to expose it. And yes there should be a new documentation section about reproducible objects and how -frandom-seed= should be used, etc.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #39 from Andrew Pinski ---
```
mkdir -p tt1/tt1
cd tt1/tt1
/home/apinski/src/tt1/gcc/worktrees/14.2.0/configure
--prefix=${HOME}/gcc-14.2.0
make -j16 && make install
```
This was my exact commands. I used with a non-relative path even. I will be
trying the trunk. Note this with a 32bit multi-lib where the failure is
happening so that might have something to do with it too.
[Bug libstdc++/35557] including pulls symbols from unistd.h in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35557 Andrew Pinski changed: What|Removed |Added CC||sinbal2l at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 116752 has been marked as a duplicate of this bug. ***
[Bug libstdc++/116752] Implementation detail leakes to header - "write" func is being pulled in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116752 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 35557 ***
[Bug c++/116750] --coverage generates random .data.rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED Keywords||documentation --- Comment #3 from Andrew Pinski --- Hmm, I thought there was a section on this.
[Bug gcov-profile/116743] [12/13/14/15 regression] Commit `3d9e6767939e` causes ~10% perf regression w AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743 --- Comment #3 from Andrew Pinski --- This is the first time I have seen someone actually using auto-fdo which I had thought was still broken and not working.
[Bug middle-end/116749] [12/13 Regression] program crash under -O3 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.5 Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- There is a builtin_unreachable from the infinite loop during unrolling. It is gone in GCC 14 though.
[Bug tree-optimization/114052] [12/13/14/15 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052 --- Comment #11 from Andrew Pinski --- Note I don't get an __builtin_unreachable() in GCC 14.1.0 nor 13.1.0.
[Bug middle-end/116749] [12/13 Regression] program crash under -O3 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749 --- Comment #2 from Andrew Pinski --- Maybe not ...
[Bug middle-end/116749] [12/13 Regression] program crash under -O3 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-17 Ever confirmed|0 |1 Resolution|DUPLICATE |--- Status|RESOLVED|NEW
[Bug middle-end/116749] [12/13 Regression] program crash under -O3 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup ... *** This bug has been marked as a duplicate of bug 114052 ***
[Bug tree-optimization/114052] [12/13/14/15 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052 Andrew Pinski changed: What|Removed |Added CC||bouncy12578 at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 116749 has been marked as a duplicate of this bug. ***
[Bug c++/116750] --coverage generates random .data.rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-17 Status|UNCONFIRMED |WAITING
[Bug c++/116750] --coverage generates random .data.rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750 --- Comment #1 from Andrew Pinski --- Try using -frandom-seed=0 or someother number.
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 Andrew Pinski changed: What|Removed |Added Target||x86_64 --- Comment #2 from Andrew Pinski --- Later today I will try to create a gimple testcase as the code has been broken since it was added in r0-107409-gbfe068c3d311b0 (for GCC 4.7.0). Note I think it was exposed starting wth r15-571-g1e0ae1f52741f7 .
[Bug tree-optimization/116747] [15 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-09-17 --- Comment #1 from Andrew Pinski --- Confirmed. Looks like this is a latent bug in cselim. Before cselim we have: ``` if (iftmp.1_29 != 0) goto ; [66.67%] else goto ; [33.33%] [local count: 59055800]: # _51 = PHI <_50(10)> _94 = f[_51]; _73 = _94 & 1; d[e.0_43] = _73; _57 = f[_51]; _58 = _57 & 1; d[e.0_43] = _58; _101 = f[_51]; _80 = _101 & 1; d[e.0_43] = _80; goto ; [100.00%] [local count: 59055800]: # _55 = PHI <_50(10)> _10 = f[_55]; _17 = _10 & 1; d[e.0_43] = _17; _63 = f[_55]; _41 = _63 & 1; d[e.0_43] = _41; [local count: 118111600]: # _53 = PHI <_55(12), _51(11)> ``` Notice how there are uneven # of stores on one side of the if. so we match up the pairs and for one of them we double up.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> I am testing a full non relative path configure now; that is:
> ```
> mkdir -p t1/t1
> cd t1/t1
> /home/apinski/src/tt1/worktrees/14.2.0/configure --prefix=${HOME}/gcc-14.2.0
> make -j16 && make install
> ```
>
> TO see if that fails.
That still fails.
So only one level subdirectory of the src directory works or an objdir outside
of the src directory will work.
[Bug target/116734] internal compiler error: in do_output_reload, at reload1.cc:7876 with atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734 --- Comment #5 from Andrew Pinski --- I still think the how the pattern for atomic_compare_and_swapsi is broken which is just causing issues elsewhere. I have no way to test a fix for atomic_compare_and_swapsi though.
[Bug target/116734] internal compiler error: in do_output_reload, at reload1.cc:7876 with atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734
--- Comment #4 from Andrew Pinski ---
init-regs adds the set to 0 for the output:
adding initialization in st_update_array_templ of reg 119 at in block 8 for
insn 75.
scanning new insn with uid = 168.
scanning new insn with uid = 169.
(insn 167 129 75 8 (set (reg:SI 119)
(const_int 0 [0])) "t.cc":51:31 39 {*movsi_internal3}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 75 167 76 8 (parallel [
(reg:SI 119)
(reg:SI 118)
(mem/v:SI (reg/v/f:SI 69 [ buffer ]) [-1 S4 A32])
(reg:SI 118)
(reg:SI 148)
(const_int 0 [0])
(const_int 32773 [0x8005])
(const_int 0 [0])
(clobber (reg:SI 157))
]) "t.cc":51:31 86 {atomic_compare_and_swapsi}
(expr_list:REG_UNUSED (reg:SI 157)
(nil)))
[Bug target/116734] internal compiler error: in do_output_reload, at reload1.cc:7876 with atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734 --- Comment #3 from Andrew Pinski --- Created attachment 59128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59128&action=edit Reduced testcase for the trunk with LRA turned off
[Bug target/116734] internal compiler error: in do_output_reload, at reload1.cc:7876 with atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734 Andrew Pinski changed: What|Removed |Added Summary|internal compiler error: in |internal compiler error: in |do_output_reload, at|do_output_reload, at |reload1.cc:7876 |reload1.cc:7876 with ||atomics --- Comment #2 from Andrew Pinski --- So this just happens to work on the trunk (and GCC 14 since switching over to use LRA rather than reload; r14-383-gfaf8bea79b6256). The problem is definitely how atomic_compare_and_swapsi is represented. Someone will have to decide if it is a bug in reload or really a bug in how atomic_compare_and_swapsi is represented in the microblaze backend. Note reverting r14-383-gfaf8bea79b6256 for the microblaze part we can reproduce it on the trunk.
[Bug target/90620] Microblaze: ICE similar to bug 16267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #6 from Andrew Pinski --- Note this is not exactly fixed just not showing up any more. See PR 116734 for one with a testcase that is failing with GCC 13.3.0 though Not the trunk.
[Bug bootstrap/116730] build is broken when building in subdirectory of a subdirectory of the src directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2024-09-16 00:00:00 |2024-09-17
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||documentation
Summary|`make install` fails when |build is broken when
|processing libbacktrace |building in subdirectory of
|while installing libstdc++ |a subdirectory of the src
|due invoking configure with |directory
|a relative path other than |
|../ |
Component|libstdc++ |bootstrap
--- Comment #11 from Andrew Pinski ---
Oh yes. This was never really supported.
We had wording in install.texi warning about this case but it was changed with
r14-6041-g875c7771097d12 because it looks like it was misunderstood what was
supported on this or not.
so in summary:
```
cd gcc
mkdir -p objdir/objdir
../../configure --prefix=${MYPREFIX}
make -jN && make install
```
fails and even using:
```
`pwd`/../../configure --prefix=${MYPREFIX}
```
fails.
The best thing is not to build two layers deap.
I am testing a full non relative path configure now; that is:
```
mkdir -p t1/t1
cd t1/t1
/home/apinski/src/tt1/worktrees/14.2.0/configure --prefix=${HOME}/gcc-14.2.0
make -j16 && make install
```
TO see if that fails.
[Bug c++/90189] Spurious "error: parameter packs not expanded" when a dependent name coincides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189
--- Comment #6 from Andrew Pinski ---
Another testcase which has the same issue with the clash from PR 116739:
```
template struct l {};
template
struct mm {
using type = t;
};
template
class myclass {
template
// error: parameter packs not expanded with '...':
l::type> try_push(type&&... k);
};
```
[Bug c++/90189] Spurious "error: parameter packs not expanded" when a dependent name coincides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189 Andrew Pinski changed: What|Removed |Added CC||ted at lyncon dot se --- Comment #5 from Andrew Pinski --- *** Bug 116739 has been marked as a duplicate of this bug. ***
[Bug c++/116739] template parameter confusion results in parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116739 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup in the end. *** This bug has been marked as a duplicate of bug 90189 ***
[Bug c++/116739] template parameter confusion results in parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116739
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
Ever confirmed|0 |1
Last reconfirmed||2024-09-17
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
template struct l {};
template
struct mm {
using type = t;
};
template
class myclass {
template
// error: parameter packs not expanded with '...':
l::type> try_push(type&&... k);
};
```
Somehow GCC is getting confused between type and m::type.
[Bug c++/116739] template parameter confusion results in parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116739 Andrew Pinski changed: What|Removed |Added URL|https://stackoverflow.com/q | |uestions/78989800/parameter | |-packs-not-expanded-with-c1 | |7-gcc-bug | --- Comment #1 from Andrew Pinski --- https://stackoverflow.com/questions/78989800/parameter-packs-not-expanded-with-c17-gcc-bug
[Bug tree-optimization/116711] Use simple_dce_from_worklist inside the vectorizer and remove the DCE after the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116711 Andrew Pinski changed: What|Removed |Added Summary|Use |Use |simple_dce_from_worklist|simple_dce_from_worklist |inside the vectorizer |inside the vectorizer and ||remove the DCE after the ||vectorizer --- Comment #4 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663099.html I will keep this open until we remove the DCE which still needs a few other changes.
[Bug c++/116741] ICE with invalid cast from void* in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116741 Andrew Pinski changed: What|Removed |Added Known to fail||14.1.0 Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.3
[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464 Andrew Pinski changed: What|Removed |Added CC||hi at alyssa dot is --- Comment #19 from Andrew Pinski --- *** Bug 116737 has been marked as a duplicate of this bug. ***
[Bug target/116737] internal compiler error: Segmentation fault from store_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116737 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup already fixed. *** This bug has been marked as a duplicate of bug 115464 ***
[Bug target/116737] internal compiler error: Segmentation fault from store_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116737 --- Comment #1 from Andrew Pinski --- Looks like it is working on the trunk ...
[Bug c++/116746] Explicit specializations of static variable templates are incorrectly given external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116746 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/35211 --- Comment #3 from Andrew Pinski --- >This appears to be a common compiler bug as both Clang and MSVC exhibit >similar behavior as can be observed at Oh I didn't read this part until after I looked to see if clang/MSVC had the same issue.
[Bug c++/116746] Explicit specializations of static variable templates are incorrectly given external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116746 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-16 Status|UNCONFIRMED |NEW Known to fail||5.1.0 --- Comment #2 from Andrew Pinski --- Confirmed. Note looks like clang and MSVC has the same issue too.
[Bug c++/116746] Explicit specializations of static variable templates are incorrectly given external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116746 --- Comment #1 from Andrew Pinski --- Created attachment 59127 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59127&action=edit Dejagnu testcase for easier testing
[Bug tree-optimization/116711] Use simple_dce_from_worklist inside the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116711
--- Comment #3 from Andrew Pinski ---
I got a bootstrap failure due to SLP not resetting the scev or freeing the
iterations estimates cache.
Reduced testcase:
```
void g(int);
void f(int *a)
{
int n = a[0]++;
int g1 = a[1]++;
for(int i = 0; i < n; i++)
g(g1);
}
```
ICE:
```
t22.cc: In function ‘void f(int*)’:
t22.cc:2:6: error: loop 1’s number of iterations ‘(((unsigned int)) +
4294967295)’ references the released SSA name ‘’
2 | void f(int *a)
| ^
during GIMPLE pass: slp
dump file: t22.cc.186t.slp1
t22.cc:2:6: internal compiler error: in verify_loop_structure, at
cfgloop.cc:1741
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug tree-optimization/116711] Use simple_dce_from_worklist inside the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116711 --- Comment #2 from Andrew Pinski --- Created attachment 59124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59124&action=edit Start of the patch Still need a full changelog. And need to boostrap/test with it. It has passed vect.exp though.
[Bug tree-optimization/116742] -Wuninitialized failed to issue uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116742 Andrew Pinski changed: What|Removed |Added Blocks||24639 Component|c++ |tree-optimization Keywords||diagnostic --- Comment #1 from Andrew Pinski --- There might be a dup of this one already. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug gcov-profile/116743] Commit `3d9e6767939e` causes ~10% perf regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743 --- Comment #1 from Andrew Pinski --- g:3d9e6767939e
[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++ due invoking configure with a relative path other than ../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 Andrew Pinski changed: What|Removed |Added Summary|`make install` fails when |`make install` fails when |processing libbacktrace |processing libbacktrace |while installing libstdc++ |while installing libstdc++ ||due invoking configure with ||a relative path other than ||../ Keywords||build Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #9 from Andrew Pinski --- So yes I can reproduce the failure but I think relative pathes other than `../` are not supported when it comes to configuring. As I mentioned invoking configure as: ``` `pwd`/../../configure ... ``` Will fix the issue.
[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 --- Comment #7 from Andrew Pinski --- (In reply to Hime Haieto from comment #6) > (In reply to Andrew Pinski from comment #4) > > > autoreconf2.69 -vfi > > > > > > Don't do this. > > Where do you think babies...I mean configure comes from? Msot of the generated files are checked into the repo. Please read https://gcc.gnu.org/install/prerequisites.html . Only Flex and Texinfo should be needed if you are building directly from the git repo.
[Bug libstdc++/116730] `make install` fails when processing libbacktrace while installing libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 --- Comment #4 from Andrew Pinski --- > autoreconf2.69 -vfi Don't do this.
[Bug libbacktrace/116730] `make install` fails when processing libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 --- Comment #2 from Andrew Pinski --- Also building in the source tree is not fully tested and is sometimes known to be broken.
[Bug libbacktrace/116730] `make install` fails when processing libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-16 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- >../../configure --prefix=/opt/gcc/14.2.0 --enable-lto This is an interesting configure line. Can you expand on which directory you are configuring from and how you get the source? I am suspect you are building in an directory which is not supported on how to do the build. That is doing: mkdir objdir cd objdir ../configure is supported BUT doing: mkdir objdir mkdir objdir/14.2 cd objdir/14.2 ../../configure is not supported. Note doing: mkdir objdir mkdir objdir/14.2 cd objdir/14.2 `pwd`/../../configure is supported because configure is given a full path.
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #8 from Andrew Pinski --- .
[Bug c++/113563] Rejects capture of `this` in C++23 `this auto` lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563 Andrew Pinski changed: What|Removed |Added CC||janschultke at googlemail dot com --- Comment #7 from Andrew Pinski --- *** Bug 116727 has been marked as a duplicate of this bug. ***
[Bug c++/116727] "this" is unusable in an explicit object member function lambda capturing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116727 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 113563 ***
[Bug c/116726] [14/15 Regression] compiler segfault when using certain struct redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Andrew Pinski changed:
What|Removed |Added
Summary|compiler segfault when |[14/15 Regression] compiler
|using certain struct|segfault when using certain
|redefinitions |struct redefinitions
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-09-15
Keywords||ice-on-valid-code
Target Milestone|--- |14.3
CC||muecker at gwdg dot de
--- Comment #3 from Andrew Pinski ---
Confirmed. Reduced slightly:
```
struct s1 {
int f1;
};
struct s2 {
int f2;
};
struct s1 f(struct s2 *);
struct s1 {
int f1;
};
struct s2 {
int f2;
};
struct s1 f(struct s2 *);
```
I think this is valid due to change in C23 tag compability.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3003.pdf .
Clang does not implement the C23 tag compatibility rules yet.
[Bug c++/116722] ICE with constexpr template constructor and floating point value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |12.5 Known to fail||12.1.0
[Bug ipa/116296] [13/14/15 Regression] internal compiler error: in merge, at ipa-modref-tree.cc:176 at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116296 --- Comment #3 from Andrew Pinski --- *** Bug 116721 has been marked as a duplicate of this bug. ***
[Bug ipa/116721] [15 Regression] ICE: in merge, at ipa-modref-tree.cc:176
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116721 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Yes PR 116296. This is an ICE with checking. *** This bug has been marked as a duplicate of bug 116296 ***
[Bug ipa/116721] [15 Regression] ICE: in merge, at ipa-modref-tree.cc:176
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116721 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-15 Ever confirmed|0 |1 Target|riscv*-*-* |riscv*-*-* x86_64 --- Comment #1 from Andrew Pinski --- Confirmed . I thought I had a dup of this one before ...
[Bug c++/116722] Internal Compiler Error: when creating a class with virtual inheritance, constexpr template constructor and call it with floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-15
Status|UNCONFIRMED |NEW
Keywords||ice-on-invalid-code
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Note GCC 11.4.0 didn't ICE but accepted the code. clang/MSVC/EDG all reject the
constexpr in a class with a virtual base class.
Without a template GCC does reject the constexpr constructor because it is a
class with a virtual base class BUT the error message is not exactly clear
there:
```
: In constructor 'constexpr derived::derived(int)':
:5:29: error: 'class derived' has virtual base classes
5 | constexpr derived(int) {}
| ^
```
(but that is a different issue all together).
[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725 --- Comment #1 from Andrew Pinski --- -masm=intel is definitely not well tested ...
[Bug middle-end/116723] performance differs in -ffinite-loop with only type changing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116723 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- (p.f0 != (-18)) For uint16_t, this is always true and is an always infinite loop. While for int16_t it is not and the loop is removed because you supplied -ffinite-loop. -ffinite-loop does NOT remove always infinite loops by design and is what is required by the C++ standard even. So invalid by design.
[Bug target/116718] bpf: support bpf_fastcall attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718 --- Comment #1 from Andrew Pinski --- Note gcc does ipa based register allocation. I wonder if most of these like attributes are just to work around llvm not doing that.
[Bug tree-optimization/116699] factor_out_conditional_operation does not ignore PREDICT/NOP sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116699 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug c++/116676] [12/13/14/15 Regression] ICE with structured bindings and std::pair with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-14 Known to work||11.4.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |12.5 Known to fail||12.1.0 Summary|GCC crashes on incorrect|[12/13/14/15 Regression] |code with -std=c++23 in |ICE with structured |'constexpr' expansion of|bindings and std::pair with |'std::get<0, const int&,|references |details::spin_sync| |>(std::)' | Keywords||needs-bisection See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=115605|
[Bug c++/116676] GCC crashes on incorrect code with -std=c++23 in 'constexpr' expansion of 'std::get<0, const int&, details::spin_sync >(std::)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676 Andrew Pinski changed: What|Removed |Added Attachment #59113|0 |1 is obsolete|| --- Comment #5 from Andrew Pinski --- Created attachment 59114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59114&action=edit Reduced testcase which uses a different definition of std::remove_reference To get it to compile with older versions of GCC (and clang), we need a slightly different definition of std::remove_reference . Note this is a regression.
[Bug c++/116676] GCC crashes on incorrect code with -std=c++23 in 'constexpr' expansion of 'std::get<0, const int&, details::spin_sync >(std::)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676 --- Comment #4 from Andrew Pinski --- Created attachment 59113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59113&action=edit Reduced testcase
[Bug c++/116676] GCC crashes on incorrect code with -std=c++23 in 'constexpr' expansion of 'std::get<0, const int&, details::spin_sync >(std::)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115605 --- Comment #3 from Andrew Pinski --- I wonder if this is related to PR 115605 .
[Bug c++/116676] GCC crashes on incorrect code with -std=c++23 in 'constexpr' expansion of 'std::get<0, const int&, details::spin_sync >(std::)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
--- Comment #2 from Andrew Pinski ---
Slightly reduced:
```
#include
namespace std {
auto [fet1, err1]
= std::pair
{ 1, 1 };
int t;
}
```
and yes the namespace here needs to be std.
[Bug c++/116676] GCC crashes on incorrect code with -std=c++23 in 'constexpr' expansion of 'std::get<0, const int&, details::spin_sync >(std::)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676 Andrew Pinski changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #1 from Andrew Pinski --- s/return 0;/int x;/ also ICEs and then it is valid code as far as I know.
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #5 from Andrew Pinski ---
(In reply to Ted Lyngmo from comment #4)
> Andrew: The reduced example you provided is not interpreted the same way as
> what I used when I wrote the report. I think they fail for different
> reasons. Possibly at different stages. I went through the language standards
> (11 and above) when I wrote the report but it was only with gcc 14+ that
> there was an issue.
Oh it is even more subtle. Note my other reduced testcase is also broken and
should be fixed too.
Here is a new reduced testcase:
```
template
inline constexpr bool is_same_v1 = __is_same_as(_Tp, _Up);
template
void foo() {
using type = decltype([](){});
type i1;
type i2;
// This passes:
static_assert(__is_same_as(type, type));
// BUT this does not pass
static_assert(is_same_v1);
};
int main() {
foo();
}
```
The direct use of __is_same_as (__is_same but didn't exist in GCC 9) works in
every version (9+) that supports C++2a (C++20) and lambda in decltype but going
through a template variable does not in GCC 14+.
[Bug testsuite/116716] gcc.c-torture/execute/pr52286.c seems broken on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116716 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.0 --- Comment #3 from Andrew Pinski --- Fixed. Since this testcase has been around for over 10 years and seeming to pass on other 16bit targets, I don't see a reason to backport the fix.
[Bug testsuite/116716] gcc.c-torture/execute/pr52286.c seems broken on 16-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116716 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-09-14 Keywords||testsuite-fail Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, I will commit the fix as obvious soon. And yes r0-115223-gb0408f13d4b317 which fixed part of this for 16bit int targets, missed the L for the inline-asm.
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work|13.3.0 | Last reconfirmed||2024-09-14 Target Milestone|--- |14.3 --- Comment #3 from Andrew Pinski --- Hmm, my reduced testcase has always failed since -std=c++2a was added while the original started in GCC 14.1.0 ...
[Bug c++/116714] [14/15 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 --- Comment #2 from Andrew Pinski --- Created attachment 59110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59110&action=edit Reduced without headers
[Bug c++/116714] [14 Regression] Inconsistent lambda type inference in function template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116714 Andrew Pinski changed: What|Removed |Added URL|https://stackoverflow.com/q | |/78985036/7582247 | --- Comment #1 from Andrew Pinski --- https://stackoverflow.com/q/78985036/7582247
