https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808
--- Comment #3 from Andrew Pinski ---
Yes this is a dup of 109920. I wonder if that should be backported or this
closed as won't fix since it is semi harmless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116808
--- Comment #2 from Andrew Pinski ---
I think there is a dup around.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807
--- Comment #2 from Andrew Pinski ---
>I used CMake for the build
Please read https://gcc.gnu.org/bugs/#need :
the complete command line that triggers the bug
(this should be expanded to say not cmake or make command line though).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116807
--- Comment #1 from Andrew Pinski ---
Can you just provide the exact GCC commands that are invoked instead of a cmake
file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116806
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116643
--- Comment #7 from Andrew Pinski ---
here is a few more that should/can be changed:
```
#define USE_FROM_PTR(PTR) get_use_from_ptr (PTR)
#define DEF_FROM_PTR(PTR) get_def_from_ptr (PTR)
#define SET_USE(USE, V) set_ssa_use_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
--- Comment #3 from Andrew Pinski ---
(In reply to James McCoy from comment #2)
> My initial bisect pointed to that, but I was using the Vim test suite as the
> good/bad check.
>
> I'm rerunning now with just the minimal reproduction to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #10 from Andrew Pinski ---
You only looked at the first error message and thought that.
I looked at:
/opt/compiler-explorer/gcc-trunk-20240921/include/c++/15.0.0/bits/locale_facets.h:2626:49:
error: expected unqualified-id before '('
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116800
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-21
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #4 from Andrew Pinski ---
https://godbolt.org/z/d1s39v57v
Does not work with either for me .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #3 from Andrew Pinski ---
(In reply to Tymi from comment #2)
> Oh, did not see that detail. It does compile with clang though.
By clang you mean with libstd++ with clang or libc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
Andrew Pinski changed:
What|Removed |Added
Target||s390x
Component|tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Summary|[14 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116643
--- Comment #6 from Andrew Pinski ---
here is the current list of files which have both PHI_RESULT and
gimple_phi_result:
gimple-streamer-out.cc
tree-call-cdce.cc
tree-cfg.cc
tree-if-conv.cc
tree-into-ssa.cc
tree-parloops.cc
tree-phinodes.cc
tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116797
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
Andrew Pinski changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97383
--- Comment #1 from Andrew Pinski ---
Note clang is worse than GCC here:
clang with libc++ does:
:8:3: error: no matching function for call to object of type 'const
__sort'
With libstdc++ clang does:
:8:3: error: no matching function for call t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
Andrew Pinski changed:
What|Removed |Added
Attachment #59167|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
--- Comment #4 from Andrew Pinski ---
Created attachment 59167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59167&action=edit
Semi reduced with some includes added back
This is the best I could get but I decided to add back tuple and co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
Andrew Pinski changed:
What|Removed |Added
Component|preprocessor|middle-end
--- Comment #5 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
--- Comment #6 from Andrew Pinski ---
But we already ignore non-existing directories passed via -I. So yes both
EACCES and ENOTDIR should be added.
Note we do warn about the case where it is not a directory:
```
[apinski@xeond2 tt]$ touch trttt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560
--- Comment #5 from Andrew Pinski ---
The question comes do we want to allow:
```
touch file
touch file.c
gcc -I./file/dir file.c
```
Or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
--- Comment #3 from Andrew Pinski ---
So maybe EACCES should be ignored too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788
Andrew Pinski changed:
What|Removed |Added
Component|driver |preprocessor
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
--- Comment #3 from Andrew Pinski ---
Reducing this further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
--- Comment #7 from Andrew Pinski ---
Reduced testcase:
```
struct s3 {
template constexpr s3(T x){}
};
template class s1;
template class s2;
template
using ali1 = s1;
template
void h() {
s2 A;
ali1 b;
}
```
The important part is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> The important part is the type alias ali1.
Even from the commit message:
```
it occurred to me that the problem is really
with alias (and concept) templates
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792
--- Comment #1 from Andrew Pinski ---
Maybe just a post processing of json is needed instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
--- Comment #6 from Andrew Pinski ---
Looks to be fixed on the trunk. Will reduce in a few.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126
--- Comment #7 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #6)
> It looks like explicit specializations are not given vague linkage. Is that
> the correct behaviour?
I wonder if that is related to PR 116746 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
--- Comment #3 from Andrew Pinski ---
Full backtrace for r15-3741-gee3efe06c9c49c :
apinski@xeond:~/src/upstream-gcc/gcc/objdir/gcc$ ./cc1 ../../../t.i -quiet -O2
-mavx2
during GIMPLE pass: vect
../mesa-/src/gallium/frontends/nine/nine_ff.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789
--- Comment #3 from Andrew Pinski ---
We need the preprocessed source as requested by https://gcc.gnu.org/bugs/
If you add -freport-bug to the command line of gcc while compiling, it will
save the preprocessed source to a file and report the fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
--- Comment #1 from Andrew Pinski ---
Looks very recent as it worked at r15-3721-ga2746e43470 .
And it was reported against r15-3737-g33ccc1314dcdb0 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791
Andrew Pinski changed:
What|Removed |Added
Summary|ICE in operator[], at |[15 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #291 from Andrew Pinski ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #7 from Andrew Pinski ---
that part comes from:
https://github.com/LLNL/RAJAPerf/blob/262dcbb405b00ebc3e3184685743e9d1199a45b6/src/apps/CONVECTION3DPA.hpp#L235
I really think that is undefined and you can't pointer casting like tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #3 from Andrew Pinski ---
(In reply to kugan from comment #2)
> Created attachment 59155 [details]
> creduce reduced file
This just compiles down to an empty loop on the trunk and in GCC 14.
It is definitely not correctly reduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #6 from Andrew Pinski ---
Link to the original source on github: https://github.com/LLNL/RAJAPerf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #5 from Andrew Pinski ---
Note I think this code has undefined code in it.
double sm0[max_DQ*max_DQ*max_DQ];
double (*u)[max_D1D][max_D1D] = (double (*)[max_D1D][max_D1D]) sm0;
That seems questionable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
Andrew Pinski changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777
--- Comment #1 from Andrew Pinski ---
The issue is due to use of _GLIBCXX_USE_CXX11_ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116776
--- Comment #2 from Andrew Pinski ---
Has the loads all been lifted?
If so this might be a dup of an unswitch issue I filed a few days ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88176
--- Comment #2 from Andrew Pinski ---
EDG also accepts this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91464
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-testcase
--- Comment #4 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #17 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91464
Andrew Pinski changed:
What|Removed |Added
Known to work||15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84030
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
--- Comment #5 from Andrew Pinski ---
GCC accepts this for C++17+ . I wonder what is causing the difference between
C++14 and C++17 in GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96821
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96821
--- Comment #8 from Andrew Pinski ---
So if I change constant_expression to be:
```
template
concept constant_expression = (b, true);
```
I noticed that GCC and clang now have different output.
I have seen this reported before too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99975
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81349
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116774
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352
Andrew Pinski changed:
What|Removed |Added
Keywords|needs-bisection |needs-reduction
--- Comment #16 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116766
--- Comment #1 from Andrew Pinski ---
I thought I had saw this one before ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
--- Comment #7 from Andrew Pinski ---
I am wondering if genmatch should generate the call to
generic_expr_could_trap_p rather than adding it to the pattern because there
could be more issues like this learking around.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
--- Comment #6 from Andrew Pinski ---
Created attachment 59143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59143&action=edit
Better reduced testcase
Here is a better reduced testcase.
The problem only shows up with these 2 patterns be
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Just a meta bug recording all of the TSVC related missed optimizations in one
place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
--- Comment #5 from Andrew Pinski ---
The easiest fix is to add:
&& !generic_expr_could_trap_p (@3)
There but I am not sure if that will always work even though
generic_expr_could_trap_p is recusive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
--- Comment #4 from Andrew Pinski ---
if (TREE_SIDE_EFFECTS (_p0)) goto next_after_fail964;
if (TREE_SIDE_EFFECTS (_p1)) goto next_after_fail964;
if (TREE_SIDE_EFFECTS (_p2)) goto next_after_fail964;
We check for SIDE_EFFECTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116772
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
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.
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 tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116770
--- Comment #2 from Andrew Pinski ---
DR482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116771
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-18
Severity|normal
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116767
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107942
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.5|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116766
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
Severity|normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-18
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
--- Comment #1 from Andrew Pinski ---
-fno-vect-cost-model hides it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116764
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 VPA
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
]
|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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116755
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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.
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Keywords||alias
Status|ASSIGNED
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.
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;
#
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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Andrew Pin
1 - 100 of 8369 matches
Mail list logo
