https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
--- Comment #3 from Scott Boyce ---
Yeah that is the same bug request. Though it is for version 11, any chance of
back-porting to version 9 and 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97973
Marek Polacek changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97973
--- Comment #3 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:40465293cd780aa82dcae75dfcfb1449d8c0561e
commit r11-7709-g40465293cd780aa82dcae75dfcfb1449d8c0561e
Author: Marek Polacek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
H.J. Lu changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #12 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #11)
> Introducing a new memory constraint can take some time.
>
> I guess we could switch off the offending code meanwhile because it is
> compiler crash vs un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99639
Bug ID: 99639
Summary: Duplicated constant in V2SI/V4SI
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Jan Hubicka changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Bug ID: 99638
Summary: s132 benchmarks of TSVC on zen3 benefits from -mno-fma
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
--- Comment #4 from Jonathan Wakely ---
I think the relevant sentence is "Each bit of the value representation of the
result is equal to the corresponding bit in the object representation of from."
For one of the bits in the result, there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
--- Comment #2 from Hana Dusíková ---
I know this is not an argument but MSVC accepts this code, meanwhile I'm asking
Richard what to do about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637
Bug ID: 99637
Summary: bit_cast doesn't work with padding bits and it should
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99636
Bug ID: 99636
Summary: [10/11 regression] gcc.dg/strlenopt-80.c fails for 32
bits
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99635
Bug ID: 99635
Summary: -Warray-bounds where -Wzero-length-bounds is expected
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
--- Comment #10 from Eric Botcazou ---
> 2021-03-17 Jakub Jelinek
>
> PR middle-end/98099
> * gcc.dg/pr98099.c: Don't compile the test on pdp endian.
> For big endian use -fsso-struct=little-endian dg-options.
>
> --- gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99620
--- Comment #4 from Paweł Bylica ---
Can you give me introduction where and how to fix it? I have a longer list of
similar issues, so maybe it's good time to learn how to fix them myself.
FYI, clang is unifying both cases by changing `k = l > a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #13 from Jakub Jelinek ---
Oops, thanks for catching that. Made those changes and restarted testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #12 from Christophe Lyon ---
I have tests in progress too (with and without the fix), except that I have
typedef uint32x4_t i;
instead of
typedef uint32x2_t i;
and I replaced the (__builtin_neon_hi *) cast with (int16_t*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
--- Comment #6 from Iain Sandoe ---
given that it blocks something else and that the fix is obvious, trivial and
confined to the coroutines implementation - my vote would be to make it.
(I do expect to touch that code if I have a chance to fix t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99179
--- Comment #2 from Iain Sandoe ---
I did some more checking on this.
1) It seems that something we produce in the unwind info for alloca is not
compatible with atos.
2) The objects all pass "dwarfdump --verify"
3) If I run the objects under l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #11 from Jakub Jelinek ---
Created attachment 50415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50415&action=edit
gcc11-pr99593.patch
Ok, trying to test this overnight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99632
--- Comment #2 from Martin Sebor ---
The definition missing from comment #0 is:
struct B { int n, a[0]; };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
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=99593
--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> Comment on attachment 50412 [details]
> proposed testcase
>
> Any reason not to replace
> __simd128_int32_t with int32x4_t ,
> __simd128_float32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99634
Bug ID: 99634
Summary: s2102 benchmarks of TSVC is vectorized better by icc
than gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235, s2233, s275 and s233 |s235, s2233, s275, s2275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235, s2233 and s233|s235, s2233, s275 and s233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235 and s233 benchmarks of |s235, s2233 and s233
|TS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235 benchmark of TSVC is |s235 and s233 benchmarks of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99633
Bug ID: 99633
Summary: s1113 benchmark of TSVC is unrolled by icc and not by
gcc and runs faster on znver3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #11 from Vladimir Makarov ---
Introducing a new memory constraint can take some time.
I guess we could switch off the offending code meanwhile because it is compiler
crash vs unoptimal generated code choice.
I'll investigate how swi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #10 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #7)
> The addition of those extra args makes clear that the function is no
> longer just testing if it is a valid address. It should be renamed.
>
I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99632
--- Comment #1 from Andrew Pinski ---
The code is chopped off and does not declare the struct B.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #19 from Martin Liška ---
(In reply to Jakub Jelinek from comment #18)
> Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
> with
> GNU ld version 2.22.52.0.1-10.fc17 20120131
> and it works fine.
> So it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #9 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #8)
> Rather than a target hook, isn't it a property of a particular constraint?
> This constraint implies "m", this one doesn't?
> Make the implies "m" behavior the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #4 from Martin Liška ---
Created attachment 50413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50413&action=edit
Reduced .gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-03-17
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99632
Bug ID: 99632
Summary: missing warning accessing a trailing zero length array
member of base class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #15)
> > LGTM. It's by Paul. He simply needs to get the testcase's dg-foo right...
> > ;-)
>
> Now I'm confused. So you consider the fix ok? Will it then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631
Bug ID: 99631
Summary: decltype of non-type template-parameter shouldn't be
const
Product: gcc
Version: 11.0
URL: https://godbolt.org/z/4YY5r3
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #9 from Jakub Jelinek ---
Comment on attachment 50412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412
proposed testcase
Any reason not to replace
__simd128_int32_t with int32x4_t ,
__simd128_float32_t with float32x4_t and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> Created attachment 50412 [details]
> proposed testcase
>
> Here is a proposal for a testcase derived from the initial description:
> - added relev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593
--- Comment #7 from Christophe Lyon ---
Created attachment 50412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412&action=edit
proposed testcase
Here is a proposal for a testcase derived from the initial description:
- added relevant dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99630
--- Comment #1 from Martin Sebor ---
It might be worth warning for any out of bounds access to trailing members of
polymorphic classes, regardless of whether the type of the complete enclosing
object is known (and known to be derived virtually).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99630
Bug ID: 99630
Summary: missing -Warray-bounds accessing a trailing array of a
virtual base class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #5 from Eric Botcazou ---
> I am very very rusty on Ada, what should I do to check that Id is good?
Probably put back the original assert on line 155.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #4 from Vittorio Zecca ---
I added
pragma Assert (Id in Name_Entries.Table'Range);
at namet.adb:156, but then I get at compile time
namet.adb:156:25: warning: condition can only be False if invalid values
present
and the build sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |SUSPENDED
--- Comment #3 from Eric Botca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99629
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
--- Comment #6 from Jonathan Wakely ---
This behaviour is what the standard (still) requires.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99629
Bug ID: 99629
Summary: Misleading diagnostic when looking up rewritten
candidate and failing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #18 from Jakub Jelinek ---
Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
with
GNU ld version 2.22.52.0.1-10.fc17 20120131
and it works fine.
So it is the linker that regressed here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
--- Comment #9 from rsandifo at gcc dot gnu.org
---
I think we should do a variation on (3): use poly-int subtraction
in rtx_vector_builder::step but force the returned value to a constant
using to_constant (). The justification is that the enc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99626
--- Comment #1 from Jakub Jelinek ---
Doesn't FAIL on i686-linux.
I wonder if it is SLOW_UNALIGNED_ACCESS or something similar that for powerpc64
-m32 causes a lot of memcpy calls not to be folded.
grep memcpy strlenopt-73.c.023t.ssa
memcpy (p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99626
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99446
--- Comment #3 from Stephan Bergmann ---
(In reply to Stephan Bergmann from comment #2)
> At least with recent GCC master (bc2127767a0076afdbc9075fda29f97f82ef7ec6),
> I can consistently reproduce the following:
what I failed to include in comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99628
Bug ID: 99628
Summary: g++ fails to do the implicit conversion when rewritten
operator<=>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #2 from Vittorio Zecca ---
Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler.
I had to take out the -gnata option to disable pragma assert that was failing.
So I do not know if this is a genuine compiler bug or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #2 from qinzhao at gcc dot gnu.org ---
NOTE, this failure is on aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Created attachment 50411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411&action=edit
testing case and script
testing case and script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
Bug ID: 99627
Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347
with -fprofile-use -fselective-scheduling
-fsel-sched-pipelining
-fsel-sched-pipelinin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
--- Comment #3 from Bill Schmidt ---
Is this going to be addressed in GCC 11? Should this be only a P3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96825
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Eric Botcazou changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Eric Botcazo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99530
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #17 from Jakub Jelinek ---
No. The point is that the compiler splits macros from each of the includes
into a separate comdat .debug_macro section, the TU .debug_macro additions
should stay but they macros from the same headers should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99504
--- Comment #3 from H.J. Lu ---
(In reply to CVS Commits from comment #2)
> The master branch has been updated by H.J. Lu :
>
> https://gcc.gnu.org/g:adf14bdbc10d4114865a08cf20020a2616039057
>
> commit r11-7701-gadf14bdbc10d4114865a08cf20020a26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99504
--- Comment #2 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:adf14bdbc10d4114865a08cf20020a2616039057
commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
Author: H.J. Lu
Date: Thu Mar 11 06:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #16 from H.J. Lu ---
(In reply to Richard Biener from comment #15)
> So as expected all of the linkers are happy with
>
> .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> .long debug_macr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #10 from Sebastiano Vigna ---
Ahem no, my correction goes in the opposite direction it should go. I'll ask
suggestions to the library authors.
I really apologize for all the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99626
Bug ID: 99626
Summary: [10/11 regression] gcc.dg/strlenopt-73.c fails for 32
bits
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #15 from Richard Biener ---
So as expected all of the linkers are happy with
.section.gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
.long debug_macro2
.section.gnu.debuglto_.debug_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #14 from Jakub Jelinek ---
Looking at current binutils, it seems to misbehave though.
If I compile:
pr99618.c:
#include
int i;
pr99618-2.c:
#include
extern int i;
int
main ()
{
return i++;
}
gcc -g3 -gdwarf-5 -O2 -o pr99618{,.c,-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
Richard Biener changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #12 from Richard Biener ---
Btw, gold happily links w/o a problem. lld (from llvm9) reports
> ld.lld -r bad.o bad.o
ld.lld: warning: relocation refers to a discarded section:
.gnu.debuglto_.debug_macro
>>> referenced by bad.o:(.rela
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #11 from Jakub Jelinek ---
It has never been global. All it needs is the start of the comdat section.
And GCC is doing it that way for 9.5 years already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #6 from Nathan Sidwell ---
Myth Plausible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #10 from Richard Biener ---
(In reply to H.J. Lu from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > I don't see how that is any different from the above. The intent is (and it
> > has been working fine for years) that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #9 from H.J. Lu ---
(In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #9 from Sebastiano Vigna ---
Finally solved: the problematic statement
if (h == NULL) h = (struct prb_node *)&tree->prb_root;
should just be
if (h == NULL) h = tree->prb_root->prb_link[0];
The position in memory of the two pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #15 from Jürgen Reuter ---
(In reply to anlauf from comment #14)
> (In reply to Jürgen Reuter from comment #13)
> > Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at
> > it as well :D
>
> LGTM. It's by Paul.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #5)
> Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
>
SHF_EXLCUDE doesn't apply to "ld -r".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #7 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #6)
> For normal non-LTO debug macro we emit:
> .section.debug_macro,"",@progbits
> .Ldebug_macro0:
> .value 0x5 # DWARF macro version number
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #5 from Richard Biener ---
(In reply to Nathan Sidwell from comment #4)
> I wonder if this was an instance of 99423?
It doesn't use any modules, so unlikely. I thought of PR99447 instead but
since it doesn't reproduce...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #6 from Jakub Jelinek ---
For normal non-LTO debug macro we emit:
.section.debug_macro,"",@progbits
.Ldebug_macro0:
.value 0x5 # DWARF macro version number
.byte 0x2 # Flags: 32-bit, lineptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
--- Comment #4 from Nathan Sidwell ---
I wonder if this was an instance of 99423?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #5 from Richard Biener ---
Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625
Bug ID: 99625
Summary: GCC does not detect narrowing in aggregate
initialization
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #4 from Richard Biener ---
(In reply to H.J. Lu from comment #3)
> This is what GCC generates:
>
> hjl@gnu-cfl-2 pr27590]$ cat bad.s
> .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> .long .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #8 from Sebastiano Vigna ---
I'm sorry, I did the test on the wrong file. No, you cannot eliminate the &,
even if the type is correct, and h can be NULL at that point. I'll ask the
libavl maintainers their opinion. We can compile with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
Richard Biener changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
H.J. Lu changed:
What|Removed |Added
Resolution|MOVED |---
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #11 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
>
> --- Comment #10 from Richard Biener ---
> So like this.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> --- a/
1 - 100 of 181 matches
Mail list logo
