https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932
--- Comment #3 from Jan-Benedict Glaw ---
Thanks a lot!
Ftr: `--with-gas` is accepted, but `--with-gnu-as` flags the inclusion of
`usegas.h`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #8 from Jan Kratochvil ---
(In reply to Andrew Pinski from comment #2)
> So the simple test is run the full GCC bootstrap/test with all languages and
> check if the testcase fails or not. I suspect it will.
It does not. Tested on Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #11 from Jonny Grant ---
As you say, in your quote from the manual, the access attribute read_only
doesn't mean there will be any access at all.
However, it doesn't seem to generate any warnings itself, maybe it is only for
the optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #10 from Jonny Grant ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Jonny Grant from comment #8)
> > So the caveat is this issue (2). I can't use attribute nonnull due to these
> > optimizations that cannot be disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #9 from Andrew Pinski ---
(In reply to Jonny Grant from comment #8)
> So the caveat is this issue (2). I can't use attribute nonnull due to these
> optimizations that cannot be disabled.
But you declare that argument cannot be null.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #8 from Jonny Grant ---
(In reply to Andrew Pinski from comment #7)
> access attribute says if it is access, then it will be that. It does not say
> it MUST be accessed. That is what nonnull is for.
>
> >I didn't want to use __attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
--- Comment #4 from Andrew Pinski ---
Yes GCC 11.x produces wrong code too, remove constexpr from uint64_x_2_t_to_ld
and temp_uint64_x_2_t_to_ld to see that:
uint64_x_2_t_to_ld:
.long 1
.long 0
.long 0
.long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
--- Comment #2 from Andrew Pinski ---
Note long double on x86_64 has padding bits which almost likely you are running
into here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
--- Comment #1 from Andrew Pinski ---
r12-7240-g2801f23fb82a5e (aka PR 104522) is what changed the behavior but I am
not 100% sure the resulting code in GCC 11 was correct ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Bug ID: 108934
Summary: bit_cast'ing to long double errors out with "the
argument cannot be interpreted" since gcc-12
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658
--- Comment #7 from Andrew Pinski ---
diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 45bf2d18639..b44335dd406 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -3089,7 +3089,8 @@ get_best_mode (int bitsize, int bitpos,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658
--- Comment #6 from Andrew Pinski ---
/* ??? For historical reasons, reject modes that would normally
receive greater alignment, even if unaligned accesses are
acceptable. This has both advantages and disadvantag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
--- Comment #6 from CVS Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:5c638095e7e0fa4de4e4f7326384a86830b25732
commit r13-6346-g5c638095e7e0fa4de4e4f7326384a86830b25732
Author: Mikael Morin
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
Andrew Pinski changed:
What|Removed |Added
Target|arm, aarch64|aarch64
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Bug ID: 108933
Summary: [10/11/12/13 Regression] Missing bswap detection
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900
Jan-Benedict Glaw changed:
What|Removed |Added
Target||avr-elf, pru-elf, rl78-elf
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932
--- Comment #1 from Andrew Pinski ---
if test x$gnu_ld = xyes; then
tm_file="usegld.h ${tm_file}"
fi
if test x$gas = xyes; then
tm_file="usegas.h ${tm_file}"
fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932
Bug ID: 108932
Summary: amd64-pc-solaris2.11:
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #27 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:05652ac4e8b8685fe0c0f4ee2f75516d28bbf892
commit r13-6343-g05652ac4e8b8685fe0c0f4ee2f75516d28bbf892
Author: Gaius Mulley
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #1 from Libin Dang ---
For this test case, `-fdump-internal-locations' gives:
...
header3.h:327614|loc:1342177760|#include "header2.h"
|7778
|788899900011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #18 from Jonathan Wakely ---
Created attachment 54537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54537&action=edit
libstdc++: Do not use memmove for 1-element ranges [PR108846]
This is a more complete patch that passes Art
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #17 from Jonathan Wakely ---
We need to change the arguments too, as that specialization takes a const _Tp*
as the input range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #4 from Costas Argyris ---
Using the manifest approach described in:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
it is possible to convert a full existing gcc + mingw-w64 toolchain (all
exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #16 from Jonathan Wakely ---
Ah gotcha.
So then something like this (untested):
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -422,16 +422,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919
jcmvbkbc at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919
--- Comment #1 from CVS Commits ---
The master branch has been updated by Max Filippov :
https://gcc.gnu.org/g:461d3c84a0e5ad045ee54631901cc953d6befa20
commit r13-6342-g461d3c84a0e5ad045ee54631901cc953d6befa20
Author: Max Filippov
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108931
Bug ID: 108931
Summary: conditional operator for variably modified types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #15 from Giuseppe D'Angelo ---
That's not what I meant; a type can be trivial(ly copyable) and move-only.
Here's a modification of Arthur's example:
// move-only
struct B {
B(int i, short j) : i(i), j(j) {}
B(B &&) = defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108906
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:d3e427f684b0cd7cedbe7b93a06f455e562c5901
commit r13-6341-gd3e427f684b0cd7cedbe7b93a06f455e562c5901
Author: Tobias Burnus
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:d3e427f684b0cd7cedbe7b93a06f455e562c5901
commit r13-6341-gd3e427f684b0cd7cedbe7b93a06f455e562c5901
Author: Tobias Burnus
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #7 from Alexander Monakov ---
I saw that. That's why I'm pointing out that Glibc (and musl) uses the
instruction without any additional checks: real CPUs produce the expected
result in st(0), despite the documentation making no promi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #6 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Alexander Monakov from comment #3)
> > I guess Uros' claim was based on what Intel and AMD manuals specify rather
> > than observed behavior of CPUs.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #5 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #3)
> I guess Uros' claim was based on what Intel and AMD manuals specify rather
> than observed behavior of CPUs.
As a "committer", I really don't remember the rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #4 from Alexander Monakov ---
Plus, Glibc does use fprem/fprem1 for fmodl/remainderl on x86_64, as well as
for {fmod,remainder,remquo}{,f,l} on i386 without any branches for corner
cases. So in practice CPUs apparently implement the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #14 from Jonathan Wakely ---
s/move an lvalue or rvalue/assign from an lvalue or rvalue/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #13 from Jonathan Wakely ---
That specialization is only used for trivial types, so moving is equivalent to
copying (otherwise we couldn't use memmove anyway). So it doesn't make any
difference whether you move an lvalue or rvalue, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920
Agner Fog changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
47 matches
Mail list logo
