https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #7 from Dave A ---
-fsanitize=address balked on the executable even without the -O2, even though
it printed out the correct values. The stack must have been initialzed and the
values persisted after the variable went out of scope.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830
--- Comment #3 from Zdenek Sojka ---
(In reply to Jakub Jelinek from comment #1)
> I certainly see a valgrind diagnostics on it:
> valgrind ./cc1 -quiet pr106830.c
> ==2461995== Memcheck, a memory error detector
> ==2461995== Copyright (C) 2002-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
--- Comment #3 from Andrew Pinski ---
(In reply to Martin Liška from comment #2)
> Fixed on master with r13-2076-g9594e04e4e2abeb4, started with
> r12-5183-ga7753db4a7c071fe.
Would make sense really but that might mean a latent bug in the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
Martin Liška changed:
What|Removed |Added
Summary|ice in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106844
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106844
Bug ID: 106844
Summary: ICE in init_use_preds, at
gimple-predicate-analysis.cc:1944 since
r13-2436-ge9ea2688271bd0b4
Product: gcc
Version: 13.0
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
--- Comment #3 from Martin Liška ---
(In reply to Jakub Jelinek from comment #1)
> See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html
I know it's caused by the revision, anything you wanted to point out in
particular?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #8 from Kewen Lin ---
Created attachment 53542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53542&action=edit
Specially handle opaque type in verify_type
(In reply to Segher Boessenkool from comment #7)
> (In reply to rguent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #6 from Andrew Pinski ---
-fsanitize=address would have told you you used the address after it went out
of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #5 from Andrew Pinski ---
6.5.2.5 Compound literals
5 The value of the compound literal is that of an unnamed object initialized by
the initializer list. If the compound literal occurs outside the body of a
function, the object has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #3 from Andrew Pinski ---
I mean compound literal not Designated initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #2 from Andrew Pinski ---
The temporary that stores the Designated initializer goes out of scope at the
end of the statement that is inside the if statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
--- Comment #1 from Dave A ---
gcc -dumpmachine
x86_64-slackware-linux
gcc -v
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/11.2.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/11.2.0/lto-wrapper
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106843
Bug ID: 106843
Summary: gcc with -O2 corrupt data on stack
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #6 from Rui Ueyama ---
If it silently produces a value that doesn't make sense, shouldn't we ban the
use of the variable or at least show a warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
--- Comment #1 from Andrew Pinski ---
The IR difference comes from PRE.
In the case where the warning happens:
find_duplicates: duplicate of
find_duplicates: duplicate of
find_duplicates: duplicate of
vs where it does not happen:
find_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
Andrew Pinski changed:
What|Removed |Added
Known to work||11.3.0, 13.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
Bug ID: 106842
Summary: misleading warning : iteration X invokes undefined
behavior
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838
--- Comment #4 from Jonathan Wakely ---
All traits of kind C currently reject T[] and T[1], but should accept them.
That applies to:
__is_empty
__is_polymorphic
__is_abstract
__has_virtual_destructor
These should accept Incomplete[] and Incomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #10 from Alexander Monakov ---
Okay, so this should have been reported against Binutils, but since we are
having the conversation here: the current behavior is not good, gas is silently
selecting a different relocation kind for no cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838
--- Comment #3 from Jonathan Wakely ---
We have three main kinds of trait preconditions.
A. "T shall be a complete type, (possibly cv-qualified) void, or an array of
unknown bound."
This only allows T[1] is T is complete, but always allows T[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
--- Comment #2 from Segher Boessenkool ---
This is inside #ifdef __ASSEMBLER__ . Running assembler code (or anything else
that isn't C) through the C preprocessor is the subject of one of my "why would
you ever do that" rants: the assembler mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:4cd0cc099cf6be818f4af1f88ce11dbfe4022dab
commit r11-10237-g4cd0cc099cf6be818f4af1f88ce11dbfe4022dab
Author: José Rui Faust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #12 from joseph at codesourcery dot com ---
The difference with __ibm128 is that in that case there is no semantic
significance to whether the low part is +0 or -0, or what the low part is
at all when the high part is a NaN. At th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
--- Comment #1 from Jakub Jelinek ---
See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:c1ba36ec779cccf6b54883d676d083df627f6d64
commit r12-8743-gc1ba36ec779cccf6b54883d676d083df627f6d64
Author: José Rui Fausti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
--- Comment #1 from David Binderman ---
This bug looks to be at least a month old, since it started sometime
before git hash 21c7aab09805d0c8, dated 20220808.
I will have a go at a reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106841
Bug ID: 106841
Summary: ice in vect_get_vec_defs_for_operand, at
tree-vect-stmts.cc:1509
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
Known to work||12.2.0
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
--- Comment #7 from Kio ---
(In reply to Andreas Schwab from comment #5)
> The operator++ function is expected to modify the argument in place, and
> needs to take a reference to it.
Yes, that's my error! after modifying the operators to:
Foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
Martin Liška changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
Bug ID: 106840
Summary: glibc master build failure on ppc64le-linux-gnu since
r13-2212-geb4879ab905308
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
Torbjörn SVENSSON changed:
What|Removed |Added
CC||torbjorn.svensson at foss dot
st.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
--- Comment #3 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:810d9815249451f477d4cbc67b8e4a0819c37faa
commit r13-2448-g810d9815249451f477d4cbc67b8e4a0819c37faa
Author: Alexander Monakov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839
--- Comment #2 from Jonathan Wakely ---
As noted in PR 106838 the library needs to guard use of
__has_virtual_destructor so it's only used with non-union class types. This
applies to trunk as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838
--- Comment #2 from Jonathan Wakely ---
The documented preconditions for __is_literal_type, __is_pod,
__is_standard_layout, and __is_trivial say:
Requires: type shall be a complete type, (possibly cv-qualified) void, or an
array of unknown boun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839
--- Comment #1 from Jonathan Wakely ---
Actually is_pod_v really should be ill-formed, so r13-25 was wrong to
allow that.
But is_final_v should be valid, and is rejected by gcc-11 and gcc-12, so
the library needs to handle that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106839
Bug ID: 106839
Summary: Library traits need to handle array of incomplete type
with unknown bound
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: reje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105682
--- Comment #8 from sagebar at web dot de ---
(In reply to Jan Hubicka from comment #6)
> I think the conlcusion here is correct. callee has pure attribute and that
> means that it has no side effects except for reading global memory. So
> whate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #24 from Jonathan Wakely ---
See PR 106838 for the __has_virtual_destructor bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838
--- Comment #1 from Jonathan Wakely ---
According to https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html the
precondition for __is_trivial is:
"Requires: type shall be a complete type, (possibly cv-qualified) void, or an
array of unknown bound.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106838
Bug ID: 106838
Summary: Built-in traits have wrong preconditions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #5 from H.J. Lu ---
To access this special symbol:
[hjl@gnu-tgl-3 tmp]$ cat c.c
#include
extern char GLOBAL_OFFSET_TABLE[];
char *ptr = GLOBAL_OFFSET_TABLE;
int main() {
printf("%lx\n", (unsigned long)ptr);
}
[hjl@gnu-tgl-3 tmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92497
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #9 from H.J. Lu ---
_GLOBAL_OFFSET_TABLE_ is a special symbol and can't be accessed like regular
symbols. To workaround it:
[hjl@gnu-tgl-3 tmp]$ cat x.c
#include
extern char GLOBAL_OFFSET_TABLE[];
int main() {
printf("%lx\n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #7 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #6)
> Ah, that special "mode". I think verify_types shouldn't do anything
> for OPAQUE_TYPES or alternatively trust the targets setup of
> TYPE_MAIN_VARIANT/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #12 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:ba0db24386107ffa237a2af0d1fdef9030460157
commit r13-2444-gba0db24386107ffa237a2af0d1fdef9030460157
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #10 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:b4d8a56a4c62ba8bca55469ae2b841fb4e1334a4
commit r13-2445-gb4d8a56a4c62ba8bca55469ae2b841fb4e1334a4
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #9 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I guess disabling them at least for now could be fine.
> > If somebody involved with dfp wants to extend it for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822
--- Comment #5 from Benjamin B. Meier ---
Thx for the very quick reaction and also you additional example:)!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #8 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> I guess disabling them at least for now could be fine.
> If somebody involved with dfp wants to extend it for dfp, it can be done
> incrementally.
>
> BTW, thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #7 from Jakub Jelinek ---
I guess disabling them at least for now could be fine.
If somebody involved with dfp wants to extend it for dfp, it can be done
incrementally.
BTW, thinking further about the singletons, I wonder if MODE_CO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #11 from Aldy Hernandez ---
Created attachment 53539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53539&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #5)
> BTW, I admit I don't know much about decimal{32,64,128}, but
> https://en.wikipedia.org/wiki/Decimal32_floating-point_format
> says:
> Because the significand i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
--- Comment #3 from Jakub Jelinek ---
True. But in the end the operator!= will be called on __begin and __end vars
which are lvalues.
So I think the test needs to be called on some trees with types of the *begin
and *end return values for which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #9 from Mathieu Malaterre ---
(In reply to Andrew Pinski from comment #3)
> If I get some time next weekend I might reduce this further to understand it.
> There are only 38 BBs in this function too and they are not large either.
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
--- Comment #2 from Ofek Shilon ---
(In reply to Andrew Pinski from comment #1)
> > In this case the begin/end iter types *are* comparable
> Not exactly as the operator!= requires a lvalue. And end() is not an lvalue.
Then enable comparison als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854
--- Comment #6 from Andrea Corallo ---
"jasonwucj at gcc dot gnu.org" writes:
[...]
>
> I guess this issue has been resolved by newlib implementation. :)
>
> Refer to the discussions on:
> https://sourceware.org/pipermail/newlib/2021/018471.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
--- Comment #1 from Andrew Pinski ---
> In this case the begin/end iter types *are* comparable
Not exactly as the operator!= requires a lvalue. And end() is not an lvalue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106837
Bug ID: 106837
Summary: False compilation error "inconsistent begin/end types
in range-based 'for' statement"
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836
--- Comment #2 from Jakub Jelinek ---
Created attachment 53538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53538&action=edit
gcc13-pr106836.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #5 from Jakub Jelinek ---
BTW, I admit I don't know much about decimal{32,64,128}, but
https://en.wikipedia.org/wiki/Decimal32_floating-point_format
says:
Because the significand is not normalized (there is no implicit leading "1"),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Andreas Schwab changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #3 from Sergei Trofimovich ---
Hm, mpfr-4.1.0 still fails these 2 tests for me from current gcc-master.
Comparing -O2 build from last week and this week snapshot code generation
changed seemingly only for `mpfr_get_decimal64()` at s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #8 from Alexander Monakov ---
Right, sorry, due to presence of 'main' I overlooked -fPIC in comment #0, and
then after my prompt it got dropped in comment #3.
If you modify the testcase as follows and compile it with -fPIC, it's evi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
--- Comment #4 from Kio ---
(In reply to Richard Earnshaw from comment #2)
> Please put testcases in the bug report, godbolt links are not stable.
test case was also attached as a file with the bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #7 from Martin Liška ---
Note I get
7: R_X86_64_GOTOFF64_GLOBAL_OFFSET_TABLE_-0x4
when I use both as 2.37 and 2.39 with the output provided by gcc-12 -fPIC:
$ cat foo.s
.file "pr106834.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #4 from Jakub Jelinek ---
I think there are ways to get around it, adding an alias to _G_O_T_ and using
that alias.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #6 from Alexander Monakov ---
(In reply to Martin Liška from comment #5)
> Do you mean gas or ld?
gas
> How did you get this output, please (from foo.o or final executable)?
>From foo.o like in comment #0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #3 from Alexander Monakov ---
It would be unfortunate if that makes it difficult or even impossible to make a
R_386_32 relocation for the address of GOT in hand-written assembly.
In any case, it seems GCC is not making the rules her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #9 from Martin Liška ---
BT:
g++ bug840.cc -c -O2 -march=bdver2
during GIMPLE pass: thread
bug840.cc: In function ‘void internal::ShortestPath()’:
bug840.cc:68:6: internal compiler error: in set_nan, at value-range.cc:283
68 | vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Martin Liška changed:
What|Removed |Added
Summary|ice in set_nan, at |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106829
Jakub Jelinek changed:
What|Removed |Added
Summary|OpenMP offload internal |[12/13 Regression] OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106836
Bug ID: 106836
Summary: [13 Regression] ICE in c_omp_split_clauses, at
c-family/c-omp.cc:2636
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #5 from Martin Liška ---
(In reply to Alexander Monakov from comment #4)
> Probably a Binutils bug then, with binutils-2.37 I get the correct
Do you mean gas or ld?
>
>4: 48 8d 05 00 00 00 00lea0x0(%rip),%rax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106823
--- Comment #1 from Richard Biener ---
I think we have a duplicate for this report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818
--- Comment #9 from Richard Biener ---
(In reply to baoshan from comment #5)
> Per Andrew's request:
>
> For GCC built for RISC-V,
> With the following code:
> struct sss_t {
> int i;
> int j;
> } sss;
> extern char array[sizeof(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106829
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106830
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816
--- Comment #5 from Richard Biener ---
The function should probably inherit all of the IPA pure/const/modref analysis
result, that is all "IPA" state should be copied. I think we want some helper
here - IPA clone creation must have something, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106815
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #6 from rguenther at suse dot de ---
On Mon, 5 Sep 2022, linkw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
>
> --- Comment #4 from Kewen Lin ---
> (In reply to Richard Biener from comment #2)
>
1 - 100 of 122 matches
Mail list logo
