https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9b4f7004a77b10bc403875f56c94f73ef86562d8
commit r13-6385-g9b4f7004a77b10bc403875f56c94f73ef86562d8
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #8 from Jakub Jelinek ---
The above commit fixed just the #c4 testcase, not the #c0 one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:85203d52bfa4a84da5f50e0a242891308ffa8d83
commit r13-6386-g85203d52bfa4a84da5f50e0a242891308ffa8d83
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108983
Bug ID: 108983
Summary: [13 Regression] Ada build is broken for Native (and
Canadian) crosses after r13-6351-ge6d39f68d03c46
Product: gcc
Version: 13.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108983
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b222e725f53231a0bd9799ca93892a79d592a5f3
commit r13-6387-gb222e725f53231a0bd9799ca93892a79d592a5f3
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:520403f324a6ed8b527f39239709dd0841b992e2
commit r13-6388-g520403f324a6ed8b527f39239709dd0841b992e2
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
Jakub Jelinek changed:
What|Removed |Added
Summary|internal compiler error: in |[11/12 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f72c8918416f67aad907752f1892c19eda12eecb
commit r13-6389-gf72c8918416f67aad907752f1892c19eda12eecb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Bug ID: 108984
Summary: [13 Regression] LTO bootstrap causes testsuite ICE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #6 from Gaius Mulley ---
Do the above fixes resolve this PR ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gaius Mulley ---
> Do the above fixes resolve this PR ?
The revised version did indeed. I'd included it in last night's
bootstraps and everything is fine again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #11 from Costas Argyris ---
Capturing another data point:
I hex-compared an executable before and after applying the UTF-8 manifest with
mt.exe just to try and see what it does, and I noticed a few things:
1) The executable size wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
Target||x86_64-linux
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-01
Keywords|needs-red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Andrew Pinski changed:
What|Removed |Added
Known to work||8.2.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #8 from Andrew Pinski ---
A slightly more reduced:
int h(int);
template
auto hh() { return 0; }
template
void mm() {
const unsigned num_elements = 1;
constexpr int dim = 1;
[&]() {
typedef d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #9 from Andrew Pinski ---
The trunk ICE is definitely lambda related:
/* Lambda closures are regenerated in tsubst_lambda_expr, not
instantiated here. */
gcc_assert (!LAMBDA_TYPE_P (template_type));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
Jakub Jelinek changed:
What|Removed |Added
Keywords|ice-on-valid-code |
--- Comment #2 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #3 from Jakub Jelinek ---
Created attachment 54564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54564&action=edit
gcc13-pr105839.patch
Untested fix for the error recovery issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #4 from northon_patrick3 at yahoo dot ca ---
Actually is still crash even on valid code:
```
template
void
foo (const T &x)
{
[&] (auto&& y)
{
#pragma omp parallel for
for (auto&& [v1, v2] : x)
;
} ([]{});
}
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #5 from Jakub Jelinek ---
Not on the trunk. Note, the r13-4460, r13-4461, r13-5379 changes PR84469
changes weren't backported to older branches intentionally, it is quite risky
and had multiple follow-ups.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:96ff97ff6574666a5509ae9fa596e7f2b6ad4f88
commit r13-6390-g96ff97ff6574666a5509ae9fa596e7f2b6ad4f88
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #4 from Richard Biener ---
So there's interesting IPA summary on gen_rtx_CONST_INT.constprop/2274667
find_slot_with_hash.constprop/2274668 function not considered for inlining
freq:0.49 loop depth: 0 size: 6 time: 15 calle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #5 from Richard Biener ---
But
void foo ();
int data[128];
static int bar (int i, int j)
{
if (j > -64 && j < 64)
return data[j+64];
foo ();
}
int baz (int j)
{
return bar (0, j);
}
seems to work fine with -O2 -fno-early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #6 from Richard Biener ---
Estimating body: gen_rtx_CONST_INT.constprop/2274667
Known to be false: not inlined, op1,((unsigned long) #),(# + 64) > 128
size:6 time:4.533600 nonspec time:7.533600 loops with known
iterations:0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #7 from Jakub Jelinek ---
Isn't what happens in i386.cc more like:
void foo (long);
int data[128];
static int bar (int i, long j)
{
if (j >= -64 && j <= 64)
return data[j+64];
foo (j);
}
int baz (unsigned int j)
{
int k =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
--- Comment #58 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:f769d22ab685671095525d09ef29d0ae3cee
commit r13-6392-gf769d22ab685671095525d09ef29d0ae3cee
Author: LIU Hao
Date: Tue May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:070523b9d4c6cfa69060255893006efaf39bf617
commit r13-6393-g070523b9d4c6cfa69060255893006efaf39bf617
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #8 from Richard Biener ---
I realized I have some value-range patches in the tree where I ran into this
(besides the pending dwarf2out change). I'm now trying to reproduce on
r13-6384-ge3837b6f6c28a1 without changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #15 from Richard Biener ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Richard Biener from comment #11)
> > We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> > The following helps:
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:3843dc1460259fbca1f336b0259f0b6b527d77ae
commit r13-6394-g3843dc1460259fbca1f336b0259f0b6b527d77ae
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #4 from David Malcolm ---
Created attachment 54565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54565&action=edit
Patch that reworks builtin handling
I've been testing this patch, but it might be too invasive at this point i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > The compiler doesn't know that the allocation function cannot clobber *this.
> > The C++ frontend tries to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #18 from Jakub Jelinek ---
Does the FE really do that?
I certainly don't see it in the gimple dump:
void X::X (struct X * const this, int k)
{
*this = {CLOBBER};
{
this->i = k;
# USE = anything
# CLB = anything
ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #19 from Jakub Jelinek ---
And on
void bar (void);
struct X {
X (int);
int i;
int j;
void baz (int);
};
X::X(int k)
{
i = k;
bar ();
j = i != k;
}
void
X::baz(int k)
{
i = k;
bar ();
j = i != k;
}
while I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81675
Marcin Kowalczyk changed:
What|Removed |Added
CC||qrczakmk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
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=108975
--- Comment #10 from Sam Mish ---
Great-- thanks for finding such a small reproducer, Andrew.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985
Bug ID: 108985
Summary: new test case gcc.dg/vect/pr108950.c from
r13-6384-ge3837b6f6c28a1 fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #20 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > where if I understand you correctly, bar () is not allowed to modify *this
> > (unless I pass it an argumen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #4 from Marek Polacek ---
I know, in principle, how to fix it, but currently I'm struggling with getting
struct A::W
from
struct A::W
That we haven't found struct A::W in class2loc is actually OK, we don't
have a A specialization, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #7 from Martin Jambor ---
The situation is that in func_61 we have an unused parameter which
IPA-SRA wants to remove. It's caller constructs the unused parameter
with the following sequence (shortened):
int func_43 (int * p_44)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #12 from Costas Argyris ---
Sent email to binutils about possible windres issue/limitation:
https://sourceware.org/pipermail/binutils/2023-March/126361.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
--- Comment #2 from Olivier Cessenat ---
integer(kind=4) valid range is -2147483648_4 to +2147483647_4.
So I consider this is a gfortran bug.
Moreover, if -2147483648_4 is considered out of range, why
-2147483647_4 - 1_4 is not ? Constant elimin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #6 from Thiago Macieira ---
Testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
--- Comment #15 from Jakub Jelinek ---
And please stop reopening this bugzilla bug. There is no bug on the GCC side,
and this should be handled on gcc-help mailing list, not here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
--- Comment #4 from Steve Kargl ---
On Wed, Mar 01, 2023 at 05:51:29PM +, cessenat at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
>
> --- Comment #2 from Olivier Cessenat ---
> integer(kind=4) valid range is -2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #7 from Thiago Macieira ---
The duplicate "note:" disappeared. But now there's no warning at all on the
same file, with the same options. Was that intended?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Bug ID: 108986
Summary: Incorrect warning for [static] array parameter
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #1 from Keith Thompson ---
A similar case. The warning refers to the size in bytes, but unlike
the first case it's not incorrect, though referring to the length
would IMHO be clearer.
Note also that the warning appears twice. It onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #8 from Andrew Pinski ---
(In reply to Thiago Macieira from comment #7)
> The duplicate "note:" disappeared. But now there's no warning at all on the
> same file, with the same options. Was that intended?
Yes that was the intent of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #9 from Thiago Macieira ---
Ah, got it. That also explains why I couldn't find anything wrong with my code,
and nothing I did that could likely be it made the warning go away.
Thanks for the quick turnaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5
commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #14 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5
commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Patrick Palka changed:
What|Removed |Added
Known to work||13.0
Summary|[12/13 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Bug ID: 108987
Summary: [13 Regression] RISC-V: shiftadd cost model bug
needlessly preferring syth_multiply
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
--- Comment #1 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613106.html
Essentially:
case PLUS:
if (TARGET_ZBA
&& mode == word_mode
&& GET_CODE (XEXP (x, 0)) == MULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Andrew Pinski changed:
What|Removed |Added
Summary|Sufficiently narrow |[13 Regression]
|term
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 54567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54567&action=edit
Updated patch
The original patches started to bit-rot, so here is an updated version.
The current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Bug ID: 108988
Summary: gimple_fold_builtin_fputs doesn't preserve
gimple_builtin_call_types_compatible_p
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #1 from David Malcolm ---
Replacement stmt is created here:
(gdb) bt
#0 gimple_set_op (gs=, i=1, op=) at ../../src/gcc/gimple.h:2629
#1 0x01093a6f in gimple_build_call_1 (fn=,
nargs=4) at ../../src/gcc/gimple.cc:234
#2 0x0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> >
> > struct foo {
> > ...
> > unsigned i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #6 from Kees Cook ---
I really want to avoid the changes to sizeof() -- this will confuse a lot of
other things. Sizeof is expected to be a constant expression, for example.
I think the attribute is best since it avoids colliding wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:de81e06273c613d7e06cbe2c8d9e72826c638056
commit r13-6400-gde81e06273c613d7e06cbe2c8d9e72826c638056
Author: Marek Polacek
Date: Th
1 - 100 of 111 matches
Mail list logo