https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889
Paul Thomas changed:
What|Removed |Added
Attachment #58586|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #10 from Sam James ---
libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce.xz:
https://dev.gentoo.org/~sam/bugs/gcc/gcc-harfbuzz-dce/libharfbuzz_subset_la-hb-subset.cc.300r.ext_dce.xz.
Too big to attach, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949
Bug ID: 115949
Summary: [SH] unrecognized insn in postreload
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #9 from Sam James ---
Created attachment 58680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58680&action=edit
libharfbuzz_subset_la-hb-subset.ii.xz
Objects were built with -O2 -march=znver2 -fno-vect-cost-model -fno-ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #8 from Sam James ---
Created attachment 58679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58679&action=edit
libharfbuzz_subset_la-hb-subset.o-no-ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #7 from Sam James ---
Created attachment 58678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58678&action=edit
libharfbuzz_subset_la-hb-subset.o-ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #6 from Sam James ---
There's only a handful of notable looking differences:
```
│ - and$0xfffd,%ecx
│ + and$0xfffd,%edx
│ + or $0x2,%ecx
│ cmpb $0x0,0xac8(%rsi)
│ - je 144f0 (hb_subset_pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115843
--- Comment #11 from Hongyu Wang ---
(In reply to Hongtao Liu from comment #10)
> > But using kmovw for QImode mask is not correct as we don't know the value in
> > gpr. Perhaps we'd consider restrict the kmovb under avx512dq only.
>
> Why? as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115843
--- Comment #10 from Hongtao Liu ---
> But using kmovw for QImode mask is not correct as we don't know the value in
> gpr. Perhaps we'd consider restrict the kmovb under avx512dq only.
Why? as long as we only care about lower 8 bits, vmovw sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115843
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112520
--- Comment #7 from Stefan Schulze Frielinghaus
---
As noted by Xi struct layouts have changed in Python 3.12. If I understand the
plugin correctly, then it should actually track those values. In order to do
so an implementation would need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115843
Hongyu Wang changed:
What|Removed |Added
CC||hongyuw at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115948
Bug ID: 115948
Summary: [SH] wrong fpu mode-switch
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82255
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
Sam James changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #7 from Andrew Pinski ---
Can you attach the file ./arch/arm64/kernel/module.lds ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #6 from Ellery ---
(In reply to Andrew Pinski from comment #5)
> So according to the linux kernel modules linker script, it should have
> combined the .plt sections.
>
> So I am thinking this is a linux kernel issue with an older ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
--- Comment #15 from Hongyu Wang ---
(In reply to Alexandre Oliva from comment #14)
> Fixed in 15. Maybe backport the last two patches to earlier branches?
Yes, I've backport the original one down to gcc13 so please do the same.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
--- Comment #15 from GCC Commits ---
The master branch has been updated by Hu :
https://gcc.gnu.org/g:a902e35396d68f10bd27477153fafa4f5ac9c319
commit r15-2052-ga902e35396d68f10bd27477153fafa4f5ac9c319
Author: Hu, Lin1
Date: Thu Jul 11 15:03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115922
Andrew Waterman changed:
What|Removed |Added
CC||andrew at sifive dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #5 from Andrew Pinski ---
So according to the linux kernel modules linker script, it should have combined
the .plt sections.
So I am thinking this is a linux kernel issue with an older version of the
kernel.
Can you show exact comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #4 from Ellery ---
(In reply to Andrew Pinski from comment #2)
> >I changed my gcc from 7.3.0 to 10.3.1 and recompiled kernel code.
>
>
> Did you change binutils version too?
binutils was changed too,
from
```
binutils-devel-2.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877
Jeffrey A. Law changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:94b21f13763638f64e83e7f9959c7f1523b9eaed
commit r15-2048-g94b21f13763638f64e83e7f9959c7f1523b9eaed
Author: Jeff Law
Date: Mon Jul 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:94b21f13763638f64e83e7f9959c7f1523b9eaed
commit r15-2048-g94b21f13763638f64e83e7f9959c7f1523b9eaed
Author: Jeff Law
Date: Mon Jul 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115947
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115947
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115916
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #14 from Andrew Pinski ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:de19b516edbf919d31e9d22fdbf6066342d904a2
>
> commit r15-1857-gde19b516edbf919d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115927
Sam James changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115947
Bug ID: 115947
Summary: ARM Thumb2 baremetal poor optimization
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #17 from Alejandro Colomar ---
(In reply to Sergei Trofimovich from comment #16)
> Sounds reasonable. Proposed possible changes upstream:
> - elfutils:
> https://patchwork.sourceware.org/project/elfutils/patch/20240715212340.
In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115897
--- Comment #4 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7954bb4fcb6fa80f6bb840133314885011821188
commit r15-2047-g7954bb4fcb6fa80f6bb840133314885011821188
Author: Patrick Palka
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115900
--- Comment #5 from Marek Polacek ---
What changed is the initializer we generate for 'd'. It used to be:
d = {.D.2656={.a={.data=0}}}
but now it is:
D::D ((struct D *) &d)
The second one causes trouble because we evaluate
((struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #8 from Jeffrey A. Law ---
Strange. My m68k bootstrap ran just fine, though I used QEMU rather than
Anarym. Andreas, I don't guess you still have enough state lying around to
get register info and some surrounding assembly code at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #16 from Sergei Trofimovich ---
Sounds reasonable. Proposed possible changes upstream:
- elfutils:
https://patchwork.sourceware.org/project/elfutils/patch/20240715212340.190915-1-sly...@gmail.com/
- strace: https://github.com/strace/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115946
Bug ID: 115946
Summary: lambda in class body should have the same type among
different TUs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #15 from Alejandro Colomar ---
(In reply to Sergei Trofimovich from comment #14)
> This generates warning on reasonably looking code.
>
> On strace-6.9:
> https://github.com/strace/strace/blob/v6.9/src/print_utils.h#L16
>
> In fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #10 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #9)
> I'm confused because, according to the DWARF spec:
>
> [is_stmt indicates] that the current instruction is a recommended breakpoint
> location. A recommende
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
Sergei Trofimovich changed:
What|Removed |Added
CC||ldv at sourceware dot org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #9 from Guinevere Larsen ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Guinevere Larsen from comment #7)
> > I understand that you could have multiple lines related to a single
> > instruction (even if I disagree it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912
--- Comment #5 from Jeffrey A. Law ---
Agreed with Pinski here. Or at least let's re-test after fixing 115916.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112520
--- Comment #6 from John David Anglin ---
Created attachment 58675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58675&action=edit
Patch to fix various segmentation faults caused by analyzer_cpython_plugin.c
With this change, we have the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > If so then the bug is in binutils's as support for the .loc, please report
> > it there instead. https://sourcewa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> If so then the bug is in binutils's as support for the .loc, please report
> it there instead. https://sourceware.org/bugzilla/ .
Maybe it is https://sourceware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #6 from Guinevere Larsen ---
I don't have experience reading debug information in this format, and I don't
know how to turn this to a format I know (gdb, readelf or objdump).
However, I think the important section would be this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #8 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #7)
> I understand that you could have multiple lines related to a single
> instruction (even if I disagree it should happen at -Og). My question is,
> why is it ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #5 from Andrew Pinski ---
Does `-gno-as-loc-support` adding work? If so this is a binutils (as) bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #4 from Guinevere Larsen ---
Sorry, I should have been more clear. This happens for the last entry of line
11, after returning from `p.get()->call()`.
> Is this a bug in binutils due to the .loc output or should the .loc output be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #3 from Andrew Pinski ---
Created attachment 58674
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58674&action=edit
output corresponding to `-gno-as-loc-support -dA`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115940
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115940
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
--- Comment #2 from Andrew Pinski ---
Created attachment 58673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58673&action=edit
-gno-as-loc-support -dA output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103868
Arsen Arsenović changed:
What|Removed |Added
CC||netcan1996 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102707
Arsen Arsenović changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #7 from Guinevere Larsen ---
I understand that you could have multiple lines related to a single instruction
(even if I disagree it should happen at -Og). My question is, why is it ok for
an entry to have is_stmt and !is_stmt for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115945
Bug ID: 115945
Summary: DW_LNE_set_discriminator emitted right before Special
Opcodes
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #6 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #5 from Andrew Pinski ---
(In reply to Guinevere Larsen from comment #4)
> Could you explain why having a single instruction be a statement and not a
> statement at once is expected?
Because that is expected with optimizations. It c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #6 from qinzhao at gcc dot gnu.org ---
This is a bug in gimple-fold.cc, when folding __builtin_clear_padding.
The problematic code is in the routine "clear_padding_type" when the TYPE is
ARRAY_TYPE.
/* For sufficiently la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
Guinevere Larsen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
--- Comment #5 from Jonathan Wakely ---
With -fPIC GCC assumes that a different definition of the functions might be
interposed later, so it emits a call (and assumes you're going to link to
another object which provides a definition without und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
--- Comment #4 from Sam James ---
Ah, Jonathan beat me to it :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
--- Comment #2 from Jonathan Wakely ---
Dereferencing a null pointer has undefined behaviour, so the compiler can
assume that function is never called. I don't think that's a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
Guinevere Larsen changed:
What|Removed |Added
Component|debug |c++
--- Comment #1 from Guinevere La
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #4 from Guinevere Larsen ---
Could you explain why having a single instruction be a statement and not a
statement at once is expected?
Or is that why you marked this bug as a duplicate of 95574?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115944
Bug ID: 115944
Summary: Incorrect code generation with -Og
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95574
Andrew Pinski changed:
What|Removed |Added
CC||blarsen at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #2 from Andrew Pinski ---
x86_64:
```
_ZN7MyClass4callEv:
.LVL0:
.LFB1:
.file 1 "/app/example.cpp"
.loc 1 7 22 view -0
.cfi_startproc
.loc 1 8 5 view .LVU1
.loc 1 8 23 is_stmt 0 view .LVU2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
--- Comment #1 from Andrew Pinski ---
Note gcc outputs .line directives usually so this could also be a binutils
issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115943
Bug ID: 115943
Summary: g++ generates contradictory line table entries
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:71ec9ed7a7353f66d55b034a45336bf43a026b1d
commit r14-10423-g71ec9ed7a7353f66d55b034a45336bf43a026b1d
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
--- Comment #4 from Manuel Lauss ---
(In reply to Andrew Pinski from comment #1)
> The .o file for LTO is not good at all.
>
> Please attach the original preprocessed sources?
>
> See
> https://gcc.gnu.org/wiki/
> A_guide_to_testcase_reduction
zlib zstd
gcc version 15.0.0 20240715 (experimental)
8f87b3c5ecd47f6ac0d7407ae5d436a12fb169dd (Gentoo 15.0. p, commit
f3f27691478a0b256a3b52348bae96f5a6b5f089)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
--- Comment #2 from Andrew Pinski ---
See https://gcc.gnu.org/bugs/#need too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115942
Bug ID: 115942
Summary: [14/15 regression] lto1: ICE in record_argument_state,
at ipa-param-manipulation.cc:2122
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
Alexandre Oliva changed:
What|Removed |Added
Summary|[13/14/15 regression] |[13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719
--- Comment #13 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:bf8e80f9d164f8778d86a3dc50e501cf19a9eff1
commit r15-2042-gbf8e80f9d164f8778d86a3dc50e501cf19a9eff1
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
--- Comment #11 from Michal Jankovič ---
(In reply to Iain Sandoe from comment #10)
> actually I thought I explained the issue in email to Michal - that we need
> to make some changes for correctness to these mechanisms and therefore that
> we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936
--- Comment #6 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> iv->step should never be a pointer type
This is created by SCEV.
simple_iv_with_niters in the case where no CHREC is found creates an IV with
base == ev, of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115936
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> iv->step should never be a pointer type
This is created by SCEV.
simple_iv_with_niters in the case where no CHREC is found creates an IV with
base == ev, of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115934
--- Comment #7 from Tamar Christina ---
(In reply to Thomas Schwinge from comment #6)
> Tamar, Richard, thanks for having a look.
>
> (In reply to Tamar Christina from comment #4)
> > This one looks a bit like costing, [...]
>
> I see. So we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115906
Arsen Arsenović changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115941
--- Comment #5 from Jonathan Wakely ---
I don't know if it's likely, but it's possible the standard will get changed to
match Clang. If that were to happen, then GCC would change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #3 from Andrew Pinski ---
https://unix.stackexchange.com/questions/780176/sysfsduplicate-plt-under-sys-modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115941
--- Comment #4 from vincent.lebourlot at starqube dot com ---
Thank you very much for the quick answer. This can be closed then.
If I understand correctly, as this follows the standard, it won't ever be
accepted anymore in gcc despite clang acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
--- Comment #2 from Andrew Pinski ---
>I changed my gcc from 7.3.0 to 10.3.1 and recompiled kernel code.
Did you change binutils version too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115937
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
Andrew Pinski changed:
What|Removed |Added
CC||rush102333 at gmail dot com
--- Comment
1 - 100 of 197 matches
Mail list logo
