https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
--- Comment #6 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:77ef91d7159613c0cfc2920ddd5a32952c61ff5b
commit r15-8022-g77ef91d7159613c0cfc2920ddd5a32952c61ff5b
Author: Robin Dapp
Date: Wed Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
--- Comment #8 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:f043ef2b6a59088b16a269b55f09023f76c92e32
commit r15-8021-gf043ef2b6a59088b16a269b55f09023f76c92e32
Author: Robin Dapp
Date: Tue Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250
--- Comment #6 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > Does anyone know why libiberty doe not install the build-time config file
> > and have libiberty.h include it?
>
> T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #4 from Jonathan Wakely ---
Ah no, because we're just using it from the makefile, not in C++ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #13 from Richard Biener ---
(In reply to Robert Dubner from comment #7)
> Well, I did ask for suggestions. I suppose it's not surprising I don't
> really understand them. Yet.
>
> I should explain, a little further, the underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #3 from Jonathan Wakely ---
I wonder if using std::filesystem (or std::experimental::filesystem for C++14)
would make this path handling more robust.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119229
--- Comment #6 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d109ad5e96ee9d31cbab0bba385fb490275a9937
commit r15-8020-gd109ad5e96ee9d31cbab0bba385fb490275a9937
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119229
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118966
--- Comment #4 from Filip Kastl ---
Yeah, it looks like this is fixed. I'll wait for the automated benchmark to
reproduce the speedup and then I'll close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265
Bug ID: 119265
Summary: unsigned __int128 not converted properly by
-fdump-ada-spec, while __int128 is
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #1 from Sam James ---
As pointed out in the CMake bug, Fedora is doing
https://src.fedoraproject.org/rpms/gcc/c/46a6d807645871b4d243ef2be35f9677bd4d68cb?branch=rawhide
but I don't know if there's a PR for that (couldn't find one).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #2 from Sam James ---
(To state the obvious: the PR119081 fix didn't solve it for this case.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
Bug ID: 119266
Summary: libstdc++.modules.json has wrong path
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218
--- Comment #15 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #14)
> Created attachment 60727 [details]
> Patch under test
>
> Please could you let me know if this works for Solaris too.
>
> (note that this does not fix the cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
--- Comment #3 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #14 from Christophe Lyon ---
Patch proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677494.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #6 from Jonathan Wakely ---
Yes for the overwhelming majority of users, it would make sense for
contrib/relpath.sh (or libstdc++-v3/src/c++23/Makefile.am) to use GNU realpath
when available.
https://www.gnu.org/software/coreutils/ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119115
Robin Dapp changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119253
Dusan Stojkovic changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Dusan Stojk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053
--- Comment #5 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:22847ef193670e761ed205a4a6f0a694b939d4e4
commit r15-8023-g22847ef193670e761ed205a4a6f0a694b939d4e4
Author: Tomasz KamiÅski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119225
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Fedora 41 only has texinfo-7.1 so I see those errors.
The fedora maintainer has kindly packaged an update for F41.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 108053, which changed state.
Bug 108053 Summary: std::visit_format_arg should hide __int128 and other
extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955
Robin Dapp changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053
Tomasz Kamiński changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267
Bug ID: 119267
Summary: RISC-V: gcc generates vsetvli with wrong LMUL with
extended assembly
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #3 from Huaqi ---
(In reply to Andrew Pinski from comment #1)
> https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Extended-Asm.html#Volatile-1
>
> Note that the compiler can move even volatile asm instructions relative to
> other code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #7 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
Andrew Pinski changed:
What|Removed |Added
CC||fanghuaqi at vip dot qq.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119278
--- Comment #2 from Sergei Trofimovich ---
Yeah, bisect landed on r15-8016-g8015a72ae49640
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #6 from Andrew Pinski ---
Funny I pointed to the same documentation as mentioned in the LLVM issue
without seeing that.
Again this is not a bug in GCC.
If you want to do some really micro-benchmarking you will need to write
everyth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119253
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #2 from Andrew Pinski ---
res = a[0] * a[0];
__asm volatile("rdcycle %0" : "=r"(end_cycle) : "r"(res) : "memory");
Will cause the second rdcycle to stay after the mult.
Otherwise you could just write the full thing in asse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #8 from Sam James ---
If something behaves identically in GCC and in Clang, that usually means it's
UB (or some intentional behaviour, or both). You can style it as a feature
request but something fundamental isn't going to change li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #5 from Huaqi ---
And for llvm part, the author topperc is looking into this issue, and try to
find a way to fix it, see
https://github.com/llvm/llvm-project/issues/130033#issuecomment-2707711817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274
--- Comment #6 from Andrew Pinski ---
Created attachment 60750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60750&action=edit
trying to get a testcase fails without std::vector
This one can be optimized in fre3 and we don't get the warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #4 from Huaqi ---
(In reply to Andrew Pinski from comment #2)
> res = a[0] * a[0];
> __asm volatile("rdcycle %0" : "=r"(end_cycle) : "r"(res) : "memory");
>
> Will cause the second rdcycle to stay after the mult.
>
> Otherw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
Bug ID: 119280
Summary: Unexpected inline asm rdcycle code misplaced cause
wrong cycle calculation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119280
--- Comment #9 from Huaqi ---
Okay, thank you Andrew and Sam for your explaination.
101 - 140 of 140 matches
Mail list logo
