https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106179
--- Comment #5 from Jason Merrill ---
*** Bug 106178 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106178
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #6 from Ulrich Drepper ---
(In reply to Marek Polacek from comment #5)
> Fixed for GCC 13. I could probably backport to GCC 12, if desirable.
Thanks. And I certainly would appreciate a backport since this is an annoying
warning in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106179
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:656c0212909bc91b1025aa12774d981adb531b4c
commit r13-1516-g656c0212909bc91b1025aa12774d981adb531b4c
Author: Jason Merrill
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106179
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:656c0212909bc91b1025aa12774d981adb531b4c
commit r13-1516-g656c0212909bc91b1025aa12774d981adb531b4c
Author: Jason Merrill
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106211
Bug ID: 106211
Summary: Rejects valid with function template with non-deduced
parameters from deduced parameters of another function
template
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #37 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #36)
> An alternative solution: for programs that are known to potentially fail due
> to built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #36 from Vincent Lefèvre ---
An alternative solution: for programs that are known to potentially fail due to
built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean up
LD_LIBRARY_PATH before executing the real progr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #35 from Vincent Lefèvre ---
And since the title of this bug was changed to mention that this is related to
the GNU gold linker, there is a runpath bug in this linker that might affect
libtool (perhaps causing it to use LD_LIBRARY_PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #34 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #33)
> (In reply to Andrew Pinski from comment #32)
> > The runpath won't work because the libraries are installed yet.
>
> This is what libtool does for GNU MPFR,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #33 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #32)
> The runpath won't work because the libraries are installed yet.
This is what libtool does for GNU MPFR, and this works fine. For instance, when
building tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #4 from Haochen Jiang ---
Created attachment 53261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53261&action=edit
This patch aims to handle memory issue when unpacking in cvtps2pd
I am trying to solve this ICE problem with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Thomas Rodgers changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165
--- Comment #5 from xeioex ---
My question is more practical. For example while `-fexcess-precision=standard`
fixes the problem in GCC. But, I am left with the same problem regarding other
compilers. At least am looking for a way to detect exces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165
--- Comment #4 from Andrew Pinski ---
(In reply to xeioex from comment #3)
> Is there a portable (across platforms and compilers) to ensure that double
> values are always 64 bits?
It is still 64bit storage on i686, just uses the excessive prec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165
--- Comment #3 from xeioex ---
Is there a portable (across platforms and compilers) to ensure that double
values are always 64 bits?
On Wed, Jul 06, 2022 at 10:15:51AM +1000, Norman wrote:
> Hi all,
>
> Consider this bit of code:
>
> unsigned int d=1,e=2,f;
>
> if((d-e) < 0)
> {
> f=d-e;
> printf("f=%i",f);
> }
>
> gcc -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c
>
> gcc compiles thi
Hi all,
Consider this bit of code:
unsigned int d=1,e=2,f;
if((d-e) < 0)
{
f=d-e;
printf("f=%i",f);
}
gcc -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c
gcc compiles this without a whimper.
However the expression (d-e) < 0 always evaluates to false (0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
Andrew Pinski changed:
What|Removed |Added
Summary|incorrect memcpy writing 1 |[12 Regression] incorrect
||std::vector::insert .
--- Comment #4 from Andrew Pinski ---
/opt/compiler-explorer/gcc-trunk-20220705/include/c++/13.0.0/bits/stl_algobase.h:431:30:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing
1 or more bytes into a region of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
Andrew Pinski changed:
What|Removed |Added
Summary|missing shrink wrap for |[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
Bug ID: 106210
Summary: missing shrink wrap for simple case
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106200
--- Comment #1 from Andrew Pinski ---
Created attachment 53260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53260&action=edit
full testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:543828e79bfa63ef26b11a2c9ea81fd7905f33aa
commit r13-1511-g543828e79bfa63ef26b11a2c9ea81fd7905f33aa
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106179
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106049
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106049
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Maybe there is a better solution.
Here's an alternative, probably more general approach that modifies
is_constant_array_expr: when the array size - as impli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106181
--- Comment #2 from Tim Lange ---
Posted a fix to the mailing list here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597871.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106209
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-07-05
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106202
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106205
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2022-07-05
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106206
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106207
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106209
Bug ID: 106209
Summary: ICE in add_init_expr_to_sym, at fortran/decl.cc:2132
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106208
Bug ID: 106208
Summary: [12/13 Regression] ICE in branch_prob, at
profile.cc:1459
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106207
Bug ID: 106207
Summary: [11/12/13 Regression] ICE in apply_fixit, at
edit-context.cc:769
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106206
Bug ID: 106206
Summary: [12/13 Regression] ICE: canonical types differ for
identical types 'int(...)' and 'int(...)'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106205
Bug ID: 106205
Summary: ICE: canonical types differ for identical types
'int()' and 'int()'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99310
--- Comment #5 from G. Steinmetz ---
ICE is reproducible with e.g. -march=nano-x2 or -march=nano-x4
(gcc configured with --enable-checking=yes)
$ gcc-13-20220703 -c pr39060.C -march=nano-x2
...
pr39060.C:19:15: internal compiler error: canonica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #31 from Artem S. Tashkinov ---
And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails:
make[3]: Entering directory '/tmp/OBJDIR/libcc1'
make[3]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p '/tmp/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #30 from Artem S. Tashkinov ---
I'm not sure why certain headers file in the resulting build have changed:
diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
--- gcc/lib/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105888
--- Comment #3 from Tim Lange ---
(In reply to Tim Lange from comment #2)
> I do have a fast prototype of this feature, but polishing that would require
> PR105888 first. I plan to work on other checkers and get more familiar with
> the code fir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105888
Tim Lange changed:
What|Removed |Added
CC||tlange at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Artem S. Tashkinov changed:
What|Removed |Added
Summary|Cannot build GCC 11.3 on|GCC 11.3 doesn't build with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204
Bug ID: 106204
Summary: False positive from
-Wanalyzer-use-of-uninitialized-value with
-ftrivial-auto-var-init=zero
Product: gcc
Version: 12.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203
Bug ID: 106203
Summary: Allow to emit diagnostics at return edges for the exit
point as well as the call site
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #28 from Artem S. Tashkinov ---
(In reply to Jonathan Wakely from comment #27)
> (In reply to Artem S. Tashkinov from comment #25)
> > Can you please try with the script I posted in comment #4?
>
> That works fine on F35 and F36.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105854
--- Comment #7 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a
commit r13-1508-g02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a
Author: Roger Sayle
Date: Tue J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96692
--- Comment #2 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:d458c53a6f37c8c49aa854d12e6867b4d914555f
commit r13-1507-gd458c53a6f37c8c49aa854d12e6867b4d914555f
Author: Roger Sayle
Date: Tue Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106202
Bug ID: 106202
Summary: internal compiler error: in move_fn_p, at
cp/decl.cc:14907
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |middle-end
--- Comment #3 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105626
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2022-07-05
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #27 from Jonathan Wakely ---
(In reply to Artem S. Tashkinov from comment #25)
> Can you please try with the script I posted in comment #4?
That works fine on F35 and F36.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
Jonathan Wakely changed:
What|Removed |Added
Depends on||94894
--- Comment #4 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
--- Comment #9 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #8)
> Just glad it's fixed. I hope my bisection didn't waste too much of anyone's
> time.
Heh, not mine. It was unlikely it was the nonzero bit patch as that just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
--- Comment #8 from Jeffrey A. Law ---
Just glad it's fixed. I hope my bisection didn't waste too much of anyone's
time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
--- Comment #3 from Jonathan Wakely ---
Reduced to not use concepts:
struct foo
{
template
foo(const T&) { }
};
struct bar { };
struct baz
{
template baz(const T&) { }
};
void f(foo&);
void f(baz, ...);
int main()
{
bar b;
f(b);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> The third one fails but not because of anything to do with borrowable
> ranges. The problem is that the filesystem::swap(path&, path&) overload is
> found by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106198
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106198
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:07dd0f7ba27d1fe9f0ce5b049ac5735dc5d361ad
commit r13-1505-g07dd0f7ba27d1fe9f0ce5b049ac5735dc5d361ad
Author: Richard Biener
Date:
ach(
std::filesystem::directory_iterator("/") | std::views::take(3),
print
);
}
the first two for_each clauses compile and execute correctly, even with g++
10.3.0.
Is my expectation that the third clause is valid incorrect?
(I just tried with today's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106200
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106200
Bug ID: 106200
Summary: Shrink-wrapping opportunity releated to function call
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192
--- Comment #3 from Michael Matz ---
(In reply to Michael Matz from comment #2)
> see why it should be. If GIMP_SIMD_LANE has properties that make this
> transformation invalid I would argue that those properties are correctly
"are _not_" I me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956
Patrick Palka changed:
What|Removed |Added
CC||byteslice at airmail dot cc
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106152
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192
--- Comment #2 from Michael Matz ---
Unroll-and-jam simply unrolls the outer loop and merged all resulting
inner-loop bodies. In this situation we have (before unroll-and-jam):
outerloop(i_1) {
_12 = i_1 <= 59
innerloop(i_1, j by 1) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106180
--- Comment #3 from Jakub Jelinek ---
That doesn't really matter, many instructions just use the g, q etc. modifiers
so that the correct Intel syntax is written, the RTL can have larger MEM just
fine, the only thing that is wrong is e.g. if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c3d2600cfb476e576fd27f3f29f49e968e86774d
commit r13-1503-gc3d2600cfb476e576fd27f3f29f49e968e86774d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106198
--- Comment #3 from Richard Biener ---
OK, that one is really the same as PR106182 but the fix there no longer works
(we don't remove a loop during fixup).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
--- Comment #20 from charles-yubo ---
As seen in godbolt, https://godbolt.org/z/qKGdPv94r , it exists in 11.3 and
12.1 with new following message :
error: array used as initializer
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220705 (experimental) [master r13-1500-g510ac273a78] (GCC)
[565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106198
--- Comment #1 from Richard Biener ---
reducing is slow but progressing, eventually fuzzers will find a simpler
duplicate as well ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106196
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1a6e0d8252a71c61d4dc616044fb25b5ac2cfffb
commit r13-1502-g1a6e0d8252a71c61d4dc616044fb25b5ac2cfffb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
康桓瑋 changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
康桓瑋 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
康桓瑋 changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment #13 from 康桓瑋
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199
Bug ID: 106199
Summary: vector::insert optimization is broken with gcc-12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #2 from Richard Biener ---
the reduction probably ended up removing the initialization as that's not
needed to reproduce the ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:0b909ae026e5aaf2ce42ef5c33128dbc06d29803
commit r10-10885-g0b909ae026e5aaf2ce42ef5c33128dbc06d29803
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106186
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
--- Comment #1 from Aldy Hernandez ---
Silly question...
In the lto1 that ICEs, we have the following in
a.ltrans0.ltrans.094t.fixup_cfg3 (i.e. before DOM even comes into the picture):
// Local variable
struct VideoFrame videoFrame;
...
..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106198
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
1 - 100 of 116 matches
Mail list logo
