https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #5 from Andrew Pinski ---
(In reply to gccbugzilla from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Once I add:
> >
> > template struct rebind {
> > typedef alloc other;
> > };
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #6 from Andrew Pinski ---
With clang and libc++ we get:
/opt/compiler-explorer/clang-trunk-20230131/bin/../include/c++/v1/__memory/uninitialized_algorithms.h:597:3:
error: static assertion failed due to requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #7 from gccbugzilla at thepirate42 dot org ---
(In reply to Andrew Pinski from comment #6)
> With clang and libc++ we get:
>
> /opt/compiler-explorer/clang-trunk-20230131/bin/../include/c++/v1/__memory/
> uninitialized_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #8 from gccbugzilla at thepirate42 dot org ---
The same code (with added rebind, https://godbolt.org/z/6fabvnvE7) compiles in
c++17 mode, while in c++20 mode (also with added rebind,
https://godbolt.org/z/ehhzYd5Wo) it doesn't, which
about c++20 mode, and the rebind isn't needed in
C++20 (because std::allocator::rebind doesn't exist, so the default
implementation of rebinding does the right thing for alloc).
(In reply to Andrew Pinski from comment #6)
> With clang and libc++ we get:
>
> /opt/compiler-expl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #6 from Andrew Pinski ---
Created attachment 54379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54379&action=edit
FortranCode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #11 from Jonathan Wakely ---
And it would be nice to simplify allocator_traits::construct using if-constexpr
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Note that for for instance gdb test-case gdb.ada/ref_param.exp, this
> convention was broken for gcc 7.5.0 (and I don't know how much earlier), and
> my current gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #8 from Kyle Shores ---
Thanks for looking into this. I believe that this worked for you, but for me,
on both my machine and in the docker container, that addition did not fix the
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #9 from Andrew Pinski ---
(In reply to Kyle Shores from comment #8)
> Thanks for looking into this. I believe that this worked for you, but for
> me, on both my machine and in the docker container, that addition did not
> fix the pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
--- Comment #11 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a9fbc6687faa09bf045c0fcee7960b7fef796fcc
commit r13-5610-ga9fbc6687faa09bf045c0fcee7960b7fef796fcc
Author: H.J. Lu
Date: Tue Jan 31 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #12 from User99627 ---
Here's some feedback.
I asked in Manjaro Forums to make it so that avr-gcc is capped to version
10.1.0. The answer has been "Manjaro uses Arch application tree".
So I created an account to Arch bugzilla and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:b533084d756a2696a3eb6521810e0a0b2182a8e8
commit r13-5611-gb533084d756a2696a3eb6521810e0a0b2182a8e8
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #13 from Andrew Pinski ---
Note it looks like type_traits uses this pattern. Though I am shocked it didn't
show up in testing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:70d34f2a30a5f1a2a09f547d92243db32d79f3f7
commit r13-5614-g70d34f2a30a5f1a2a09f547d92243db32d79f3f7
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
Bug ID: 108620
Summary: internal compiler error: in instantiate_type, at
cp/class.cc:8742 when assign the return value of
co_yield to a member of class/struct
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #1 from owent ---
Sorry, there are some problem in the source above. I commit another source and
report file.And clang 15 can compile and run successfully(
https://godbolt.org/z/d5M9ca567 ).
## Command and output
```
$ g++ test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #2 from owent ---
Created attachment 54381
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54381&action=edit
The new report file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
Bug ID: 108621
Summary: [12 regression]: bind(c) pointer array spurious
maybe-uninitialized warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #9 from Hongtao.liu ---
>
>
> decode_options() {
> int flag = 1;
> for (; flag <= 1 << 21; flag <<= 1)
> ;
> }
>
>
>
> compile with gcc -fprofile-generate -mcpu=neoverse-v1 -Ofast opts.i
Reproduced with cross-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #7 from Khem Raj ---
in Yocto we build outside the source tree. And during cross-build it will copy
aarch64.h into builddir and use it from there but then build can not find files
it includes since its being included from builddir. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #8 from Andrew Pinski ---
(In reply to Khem Raj from comment #7)
> in Yocto we build outside the source tree. And during cross-build it will
> copy aarch64.h into builddir and use it from there but then build can not
> find files it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Khem Raj from comment #7)
> > in Yocto we build outside the source tree. And during cross-build it will
> > copy aarch64.h into builddir and use it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #10 from Khem Raj ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Khem Raj from comment #7)
> > > in Yocto we build outside the source tree. And during cross-build it wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #11 from Andrew Pinski ---
(In reply to Khem Raj from comment #10)
>
> you are right. I should have mentioned that these copying is done by yocto
> builds for working though its notion of multilibs [1]. However, I think if
> we app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108622
Bug ID: 108622
Summary: x86 -fno-pic: use DW_EH_PE_indirect|DW_EH_PE_pcrel for
personality/ttype encoding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
Jan Kratochvil changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #10 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #9)
> >
> >
> > decode_options() {
> > int flag = 1;
> > for (; flag <= 1 << 21; flag <<= 1)
> > ;
> > }
Normally when vf is not constant, it will be preve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #19 from rguenther at suse dot de ---
On Tue, 31 Jan 2023, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
>
> --- Comment #18 from Tamar Christina ---
> > >
> > > Ack, that also tracks wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #11 from rguenther at suse dot de ---
On Wed, 1 Feb 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
>
> --- Comment #10 from Hongtao.liu ---
> (In reply to Hongtao.liu from comment #9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108622
--- Comment #1 from Fangrui Song ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611081.html [PATCH]
x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #12 from Hongtao.liu ---
> When the VF is not known we usually do not require an epilogue? If
> we don't require one we should avoid creating one.
I may not be very clear in my description， here gdb shows.
(gdb) p vf
$1 = {> = {co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97258480438db77e52f4b3947fa2c075b09d3fe1
commit r13-5617-g97258480438db77e52f4b3947fa2c075b09d3fe1
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #13 from fiesh at zefix dot tv ---
User99627, a few points:
* My test case does require lto to be present. There's nothing to be gained
from your statement that the bug doesn't require lto, there are test cases for
either case. The
101 - 142 of 142 matches
Mail list logo
