https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5c11d748564c7ce3b096e87ad350fcddd493e45e
commit r13-4489-g5c11d748564c7ce3b096e87ad350fcddd493e45e
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:16debfadbd759f9933b4a62029661f01188ad928
commit r12-8959-g16debfadbd759f9933b4a62029661f01188ad928
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107956
Richard Biener changed:
What|Removed |Added
Known to work||12.2.1, 13.0
Status|ASSIGN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107963
Richard Biener changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107964
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107964
--- Comment #1 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:824542bec24c09319fa55922a0162209a5f64963
commit r13-4490-g824542bec24c09319fa55922a0162209a5f64963
Author: Scott Snyder
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Richard Biener changed:
What|Removed |Added
Component|c |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #2 from Jonathan Wakely ---
They're nothing the printers can do. You're asking to print them out before
they are initialized, so they try to interpret garbage as values. The
OverflowError is just because some uninitialized std::strin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #3 from Richard Biener ---
(In reply to Jonathan Wakely from comment #2)
> They're nothing the printers can do. You're asking to print them out before
> they are initialized, so they try to interpret garbage as values. The
> Overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
Bug ID: 107969
Summary: ICE in extract_insn, at recog.cc:2791 since
r13-3292-gc2565a31c1622ab0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #4 from Richard Biener ---
I would suggest to make the pretty-printers more robust with respect to memory
errrors (can those errors be catched and the printing avoided somehow?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970
Bug ID: 107970
Summary: ICE in extract_insn, at recog.cc:2791 since
r13-2730-gd0c73b6c85677e67
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
--- Comment #1 from Andrew Pinski ---
Almost nobody uses msoft-float on x86_64 or even i386 these days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
Bug ID: 107971
Summary: linking an assembler object creates an executable
stack
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #2 from caiyinyu ---
I tested with latest gcc(commit 102f3cef568), and these fails still exist.
My gcc configuration:
../configure --prefix=/usr --libdir=/usr/lib64 --disable-bootstrap
--enable-__cxa_atexit --enable-threads=posix -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
--- Comment #2 from Martin Liška ---
Sure, it's a result of option fuzzing, I admit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
--- Comment #2 from Andrew Pinski ---
You can use the assembler note to communicate to the linker that the assembly
code does not use executable stack. This is all documented in the linker
documentation and is not part of gcc documentation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:44c8402d35160515b3c09fd2bc239587e0c32a2b
commit r13-4491-g44c8402d35160515b3c09fd2bc239587e0c32a2b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:44c8402d35160515b3c09fd2bc239587e0c32a2b
commit r13-4491-g44c8402d35160515b3c09fd2bc239587e0c32a2b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 107839, which changed state.
Bug 107839 Summary: spurious "may be used uninitialized" warning while all uses
are under "if (c)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|The gcc commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
--- Comment #3 from Andrew Pinski ---
https://sourceware.org/binutils/docs-2.39/ld/Options.html#index-_002d_002dwarn_002dexecstack
```
Note: ELF format input files specify that they need an executable stack by
having a .note.GNU-stack section w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4500baaccb6e4d696e223c338bbdf7705c3646dd
commit r13-4492-g4500baaccb6e4d696e223c338bbdf7705c3646dd
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
--- Comment #4 from Alexander Pick ---
Thanks a lot for the explanation. Do you think that it is worth reporting it to
binutils as the text in the link also says that there should be a warning
unless the option to have an executable stack is exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #6 from Jonathan Wakely ---
Reading symbols from p...
(gdb) start
Temporary breakpoint 1 at 0x4022ea: file p.cc, line 18.
Starting program: /tmp/p
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:109148dd16e4bcd50faee19c49082de69d0ba26e
commit r13-4493-g109148dd16e4bcd50faee19c49082de69d0ba26e
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #13 from Brjd ---
I am not sure how I can run only this patched test against the newly built gcc.
Would you post instruction how it is done. I know it can run in the build tree
when building gcc itself, but never test it against the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #14 from Brjd ---
Maybe it is better if we test it in the next release 12.3 or 13.1 since now the
test will be correct, ok, but when building source with the compiler, it will
not make any difference and make no problems at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #15 from Martin Liška ---
Sure, I'm pretty sure about what's the problem, so you can wait for 13.1 or
12.3 where I would like to get the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #10 from Alexander Monakov ---
If anyone is confused like I was, the commit actually includes a testcase, but
the addition is not mentioned in the Changelog. I was sure the server-side
receive hook was supposed to reject such incompl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #11 from Martin Liška ---
> I was sure the
> server-side receive hook was supposed to reject such incomplete Changelog,
> though?
New files in test-suite are not mandatory by the hook and corresponding
ChangeLog entries are generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #16 from Brjd ---
I mean that as I can see, your patch makes changes only to the test and not to
the compiler ? If it does not, and it changes the compiler source also, then I
have to rebuild the whole compiler to test it again. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #17 from Martin Liška ---
(In reply to Brjd from comment #16)
> I mean that as I can see, your patch makes changes only to the test and not
> to the compiler ?
No, it also modifies:
gcc/config/i386/i386-builtins.cc
which is part o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #21 from Tomasz Kłoczko ---
On emore time.
You are commenting under GNU C Compilet issue during linking firebird binaries
linking.
*COMPILER* (not firebird) is core dumping.
Please discuss firebird issue opening ticket on
https://gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #22 from Sam James ---
(In reply to Tomasz Kłoczko from comment #21)
> On emore time.
> You are commenting under GNU C Compilet issue during linking firebird
> binaries linking.
> *COMPILER* (not firebird) is core dumping.
>
> Pleas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #23 from Martin Liška ---
(In reply to Tomasz Kłoczko from comment #21)
> On emore time.
> You are commenting under GNU C Compilet issue during linking firebird
> binaries linking.
> *COMPILER* (not firebird) is core dumping.
I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #2 from Siddhesh Poyarekar ---
The standard does not allow the nesting, but gcc supports it as an extension.
The middle end does see the array as a flex array correctly, but
tree-object-size doesn't seem to do the right thing consis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #7 from Aldy Hernandez ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #18 from Brjd ---
Then rebuild is necessary and impending
gcc/config/i386/i386-builtins.cc for the compiler ?
gcc/testsuite/gcc.target/i386/builtin_target.c for the test ?
gcc/doc/extend.texi is not needed since I am not buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #19 from Martin Liška ---
(In reply to Brjd from comment #18)
> Then rebuild is necessary and impending
> gcc/config/i386/i386-builtins.cc for the compiler ?
> gcc/testsuite/gcc.target/i386/builtin_target.c for the test ?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107972
Bug ID: 107972
Summary: backward propagation of finite property not performed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107972
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
ing treated as errors
this happens with:
gcc version 12.2.1 20221130 (GCC)
gcc version 11.3.1 20221205 (GCC)
gcc version 10.4.1 20221205 (GCC)
but did not happen with:
gcc version 9.5.0 (GCC)
nor does it happen with:
gcc version 13.0.0 20221130 (experimental) (GCC)
It is pretty annoying because t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d492d50f644811327c5976e2c918ab6d906ed40c
commit r13-4494-gd492d50f644811327c5976e2c918ab6d906ed40c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
Richard Biener changed:
What|Removed |Added
Known to fail||12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107960
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
Martin Liška changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #13 from Martin Liška ---
> As a hack I've removed them manually:
> FOR_EACH_BB_FN (bb, cfun)
> {
> gimple_stmt_iterator gsi = gsi_after_labels (bb);
> if (!gsi_end_p (gsi) && gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT)
> gsi_rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #20 from Brjd ---
The test gcc/testsuite/gcc.target/i386/builtin_target.c is patched.
But gcc/config/i386/i386-builtins.cc looks like it is from another version.
I attached it as i386-builtins-orig-12.2.0.cc to compare them and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #21 from Brjd ---
Created attachment 54012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54012&action=edit
i386-builtins-orig-12.2.0.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #4 from rguenther at suse dot de ---
On Mon, 5 Dec 2022, siddhesh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
>
> --- Comment #2 from Siddhesh Poyarekar ---
> The standard does not allow the nes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #8 from Richard Biener ---
(In reply to Aldy Hernandez from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to Jakub Jelinek from comment #0)
> > > ... but then
> > > comes dom2 and happily replaces
> > > _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #22 from Brjd ---
Maybe not changing now is the correct way for now since I may change it blindly
not knowing completely what I am doing. Let the developers correct it and will
include it in next releases. The compiler is excellent a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2020-06-03 00:00:00 |2022-12-5
--- Comment #19 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to rguent...@suse.de from comment #4)
> Does it allow the nesting when nested in a union?
data[] cannot be nested directly in a union (i.e. union { char d; char data[];
} is invalid) but some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #13 from Richard Biener ---
There's been some changes on trunk but the preprocessed source doesn't work
there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
--- Comment #27 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0d14720f93a8139a7f234b2762c361e8e5da99cc
commit r13-4495-g0d14720f93a8139a7f234b2762c361e8e5da99cc
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
Bug ID: 107974
Summary: compiler can't find source file in path that is longer
than 255 characters
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107957
--- Comment #1 from Jacek Wieczorek ---
A little correction - I just noticed my mistake. Assembly for rawr() is in fact
correct. Apparently this happens only for variables longer than 16 bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #1 from Cristian Adam ---
Visual C++ 2022 also suffers from the same problem, see
https://developercommunity.visualstudio.com/t/compiler-cant-find-source-file-in-path/10221576
For some reason clang is working fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #2 from Andrew Pinski ---
GCC just does:
file->fd = open (file->path, O_RDONLY | O_NOCTTY | O_BINARY, 0666);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #8)
> (In reply to Aldy Hernandez from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > (In reply to Jakub Jelinek from comment #0)
> > > > ... but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
--- Comment #4 from Jakub Jelinek ---
I mean should fix the ICE, nothing else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #14 from Thiago Macieira ---
Created attachment 54015
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54015&action=edit
qfutureinterface.cpp preprocessed [gcc trunk-20221205]
(In reply to Richard Biener from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #5 from Jakub Jelinek ---
(In reply to caiyinyu from comment #2)
> I tested with latest gcc(commit 102f3cef568), and these fails still exist.
Do the glibc test logs provide some details on what exactly failed, if it is a
wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #3 from Cristian Adam ---
I've used the manifest tool from Visual C++ (mt.exe) to inject this manifest:
http://schemas.microsoft.com/SMI/2016/WindowsSettings";>
true
with the command line:
mt.exe -nologo -man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #4 from Cristian Adam ---
The manifest file is being mentioned at
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #5 from Cristian Adam ---
Created attachment 54016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54016&action=edit
gcc long path working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Bug ID: 107975
Summary: [13 Regression] frange ICE since r13-4492
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #13 from David Faust ---
Created attachment 54017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54017&action=edit
DATASEC entries for extern funcs
Applies on top of 54002: updated patch
Adds emission of DATASEC entries for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Jason Mer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
--- Comment #1 from Jakub Jelinek ---
The testcase was guessed from the
https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
--- Comment #2 from Bernd Edlinger ---
Thanks,
I see a very similar warning with
m68k-linux-gnu-gcc but without sanitizer:
crypto/modes/cfb128.c: In function 'CRYPTO_cfb128_encrypt':
crypto/modes/cfb128.c:117:33: error: writing 1 byte into a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
--- Comment #5 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
>
> using difference_type = iterator_t>;
>
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #11 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #10)
> A lot of the problem here is that building a std::string involves building a
> std::allocator temporary to pass to the string constructor, and then
> we need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
Bug ID: 107976
Summary: ICE: SIGSEGV (stack overflow) in
emit_case_dispatch_table (stmt.cc:783) with large
--param=jump-table-max-growth-ratio-for-speed
Product: gcc
1 - 100 of 155 matches
Mail list logo
