https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #13 from H.J. Lu ---
A binutils patch is posted at
https://sourceware.org/pipermail/binutils/2024-June/135259.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115698
--- Comment #6 from Yihan Dang ---
(In reply to Andrew Pinski from comment #5)
> Filed https://github.com/libhugetlbfs/libhugetlbfs/issues/88 for the
> libhugetlbfs issue.
Thank you very much for the help! I have submitted a pull request to thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #2 from Peter Bergner ---
(In reply to Kewen Lin from comment #0)
> As Peter found in the PR115688, there isn't a warning for:
>
> long __attribute__ ((target ("no-altivec,vsx")))
> foo (void)
> {
> return 0;
> }
>
> It's expecte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #8 from Kewen Lin ---
> > -mabi={no-,}altivec is only for the 32-bit ABIs. All the 64-bit ABIs had
> > either only compatible changes to support VMX, or only ever had support for
> > it in the first place.
> In that case, -mabi=no-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115714
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115714
Bug ID: 115714
Summary: rs6000: Refine option -mabi={no-}altivec handlings
with some related option
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #1 from Kewen Lin ---
There IS a warning for:
long __attribute__ ((target ("vsx,no-altivec")))
foo1 (void)
{
return 0;
}
, interesting. :)
It's due to that we enable altivec when parsing vsx in target attribute, but
don't consid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
Kewen Lin changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2024-06-30
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
Bug ID: 115713
Summary: rs6000: Miss warning for incompatible no-altivec and
vsx in target attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115698
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/libhuget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115698
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115698
--- Comment #3 from Yihan Dang ---
Hello Andrew, thank you very much for your reply! I think I've found the catch:
Change the custom ld script to this:
```
#!/bin/bash
echo "hello from custom ld, arguments are: $*"
filename=$1
filename=${filen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #11 from H.J. Lu ---
Created attachment 58541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58541&action=edit
A testcase
[hjl@gnu-tgl-3 tmp]$ g++ -c -O2 x.cc -ansi
[hjl@gnu-tgl-3 tmp]$ readelf -rW x.o | c++filt | grep -E "(ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565
Maciej W. Rozycki changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |macro at orcam dot me.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115565
--- Comment #4 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:69bc5fb97dc3fada81869e00fa65d39f7def6acf
commit r15-1724-g69bc5fb97dc3fada81869e00fa65d39f7def6acf
Author: Maciej W. Rozycki
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115694
Andrew Pinski changed:
What|Removed |Added
Keywords|lto |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115694
--- Comment #10 from Sam James ---
r13-1762-gf9d4c3b45c5ed5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65632
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112109
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:42946aa9b3228262e413481a3193bda85c20ef4b
commit r15-1723-g42946aa9b3228262e413481a3193bda85c20ef4b
Author: Sergei Lewis
Date: Sat Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91677
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82450
--- Comment #6 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/AANLkTikW8W=rjonaqigggtjkb-_2sp5zaztjcamzj...@mail.gmail.com/T/#m358ef4c2bef77b1942d29d0a5787591e754ec5bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Andrew Pinski changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #10 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Sam James changed:
What|Removed |Added
Summary|[15 regression] Binutils|[15 regression] Binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115709
--- Comment #1 from Andrew Pinski ---
aarch64 is fine since it has load_lanes:
.L4:
ld2 {v30.2d - v31.2d}, [x4], 32
fmulv31.2d, v31.2d, v31.2d
fmlav31.2d, v30.2d, v30.2d
str q31, [x3], 16
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> r15-571-g1e0ae1f52741f7 is my guess.
The reason is the DSE is able to remove the store due to the clobbers and then
dce finally can remove the operator new/oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #5 from Andrew Pinski ---
r15-571-g1e0ae1f52741f7 is my guess.
But this code is questionable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115691
--- Comment #3 from John David Anglin ---
Problem introduced by the following change:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0b27d5ddb2ce7353a168c60c9109b4ee01e481eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #4 from Sam James ---
I'm going to bisect it next as C++ semantics with new/delete isn't something
I'm yet very experienced with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #3 from Sam James ---
In cgraph:
```
@@ -1222,16 +1222,7 @@ _ZdaPv/82 (void operator delete [](void*))
Referring:
Availability: not_available
Function flags: replaceable_operator_delete
- Called by: main/76 (1073312328 (est
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #2 from Sam James ---
Between 14 and 15, the main difference is:
```
│ :
│ main():
│ /tmp/gcc-binutils-PR115712/dl5.cc:45
│ sub$0x8,%rsp
│ -/tmp/gcc-binutils-PR115712/dl5.cc:46
│ - mov$0x58,%edi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
--- Comment #1 from Sam James ---
Created attachment 58540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58540&action=edit
gcc-binutils-PR115712.tar.xz
g++ -g -O2 -D_GNU_SOURCE -ansi -c dl5.cc -o dl5.o
g++ -g -O2 -D_GNU_SOURCE -ansi -fPI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712
Bug ID: 115712
Summary: [15 regression] Binutils testsuite fails 2 tests
(libnew1a.so, libnew1b.so)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115710
Andrew Pinski changed:
What|Removed |Added
Known to work||5.5.0
Summary|fortran comple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115710
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-06-29
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115060
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 115707, which changed state.
Bug 115707 Summary: [15 regression] FAIL in gcc.target/aarch64/sve/sad_1.c
since r15-863-ga3aeff4ce95b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115707
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115060
Andrew Pinski changed:
What|Removed |Added
CC||thiago.bauermann at linaro dot
org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115707
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #11 from Alejandro Colomar ---
(In reply to Konstantin Kharlamov from comment #10)
> (In reply to Alejandro Colomar from comment #7)
> > (In reply to Konstantin Kharlamov from comment #5)
> > > So basically -Wc++-compat warns about e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #10 from Konstantin Kharlamov ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are doz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115711
Bug ID: 115711
Summary: Fortran: extra malloc and copy with transfer
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #10 from Andi Kleen ---
-fno-thread-jumps fixes it, so it's probably a dup of PR109071 (same problem
with a different warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115710
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #9 from Alejandro Colomar ---
(In reply to uecker from comment #8)
> Have you considered adding the alloc_size attribute to your allocation
> functions?
I didn't know about it; I will do. Thanks! :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115710
Bug ID: 115710
Summary: fortran complex abs does not vectorise
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #8 from uecker at gcc dot gnu.org ---
(In reply to Alejandro Colomar from comment #7)
> (In reply to Konstantin Kharlamov from comment #5)
> > So basically -Wc++-compat warns about every heap memory allocation, of which
> > there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
Alejandro Colomar changed:
What|Removed |Added
CC||alx at kernel dot org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115696
--- Comment #2 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/656022.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
--- Comment #6 from Sam James ---
Ah, great, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115709
Bug ID: 115709
Summary: missed optimisation: vperms not reordered to eliminate
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
--- Comment #1 from porten at kde dot org ---
Getting the same for similar code with gcc 14.1.1 20240629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
--- Comment #5 from uecker at gcc dot gnu.org ---
(In reply to Sam James from comment #3)
> (In reply to Richard Biener from comment #2)
> > Possibly type verification should be triggered from rest_of_type_compilation
> > rather than from (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727
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=114019
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:7682d115402743090f20aca63a3b5e6c205dedff
commit r15-1722-g7682d115402743090f20aca63a3b5e6c205dedff
Author: Harald Anlauf
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573
Albert Netymk changed:
What|Removed |Added
CC||albertnetymk at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115696
uecker at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115185
--- Comment #5 from Konstantin Kharlamov ---
(In reply to Konstantin Kharlamov from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > It is included in -Wc++-compat .
>
> Cool, thanks! I'll add the warning to the list we compile the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #36 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:378f50f4c32af5111893989bfc5a191d3aa27bb7
commit r11-11550-g378f50f4c32af5111893989bfc5a191d3aa27bb7
Author: Francois-Xavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
--- Comment #5 from Jonathan Wakely ---
P2825 would be very useful here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #14 from Jonathan Wakely ---
Gašper has confirmed that the intention is for it to be SFINAE-friendly, so
declcall would work here (and for [comparisons.general],
[comparisons.three.way], and [range.cmp], although P2434 might make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115708
Bug ID: 115708
Summary: gcc fails to identify valid friend function
declaration with deduced return type
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115707
--- Comment #2 from Feng Xue ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
This is known to be another new bug, and has been recorded in PR115060.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101485
--- Comment #13 from Jonathan Wakely ---
Yes I've read it but it's not clear to me that it's SFINAE-friendly when the
expression resolves to a built-in like that.
75 matches
Mail list logo
