function ‘void foo(const std::string&)’:
meow.cc:5:43: note: ‘d’ declared here
5 | void foo(const std::string & s) { Derived d{{}, s}; }
| ^
```
Also reproduces in trunk 20240315 from godbolt here:
https://godbolt.org/z/d7z5ErM71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #2 from Angelo Landi ---
(In reply to Andrew Pinski from comment #1)
> > Due to an integer overflow
>
> Hmm, I don't think this is an integer overflow but rather due to wrapping.
> Yes there is a difference as overflow is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #8 from Sam James ---
(For my own benefit for future reference: I ran go build -work -v -x, then went
into the work dir it made, then ran /usr/lib/go/pkg/tool/linux_amd64/link -v
..., then started pulling out the bits it ran manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #7 from Sam James ---
With some finagling:
```
/tmp/go-PR113204 $ ./run.sh
+ gcc -o test -Wl,--export-dynamic-symbol=_cgo_panic
-Wl,--export-dynamic-symbol=_cgo_topofstack
-Wl,--export-dynamic-symbol=crosscall2 -Wl,--export-dynamic-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #6 from Sam James ---
I managed to run the test manually in `/usr/lib/go/src/cmd/link` with `go test
cgo_test.go -x -v` and made writeTempFile dump the name/contents.
At least now I can reproduce with just one command outside of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #1 from Andrew Pinski ---
> Due to an integer overflow
Hmm, I don't think this is an integer overflow but rather due to wrapping. Yes
there is a difference as overflow is undefined behavior while wrapping is
defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
Bug ID: 114359
Summary: std::binomial_distribution hangs in infinite loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #16 from Andrew Pinski ---
So what is interesting is the way LLVM implements this as an IPO pass as how I
described in comment #8, 6 years after I wrote that. Well they used "empty"
rather than const . Note using it as an IPO pass I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #4 from Eugene Rozenfeld ---
auto-profile currently doesn't guarantee that it will set probabilities on all
edges because of zero basic block counts. Normally those edges just have
probabilities set by the preceding profile_estimate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934
Andrew Pinski changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #21 from Jerry DeLisle ---
The following may be a helpful read.
https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=formatting-value-separators
I am auditing our list_read.c code for the various types. The NULL read plays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #7 from Jonathan Wakely ---
Libstdc++ has to use some sneaky hacks to avoid destroying globals, we would
definitely use no_destroy if we had it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #15 from Andrew Pinski ---
The patch is able to handle all 3 testcases here even:
For the libstdc++ one:
t3.cc.123t.dce2:Deleting : __cxxabiv1::__cxa_atexit (__dt_comp , &global,
&__dso_handle);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114358
Bug ID: 114358
Summary: [13 Regression] ICE in change_address_1, at
emit-rtl.cc:2287 on m68k-linux-gnu
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:847391913443069358986b398c2f86dac906d742
commit r13-8454-g847391913443069358986b398c2f86dac906d742
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #62 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9f255e4baac68fc3568820cdca9412f67ff07940
commit r13-8451-g9f255e4baac68fc3568820cdca9412f67ff07940
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
--- Comment #12 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:3d231faed146352543794bf9e9afbee2e6c76889
commit r13-8453-g3d231faed146352543794bf9e9afbee2e6c76889
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:6b69cbe2c85f0b8f4a5a6b23e257d69275bea182
commit r13-8448-g6b69cbe2c85f0b8f4a5a6b23e257d69275bea182
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1c907cee6163a3ec2c0edaebeace73e2d32835ee
commit r13-8450-g1c907cee6163a3ec2c0edaebeace73e2d32835ee
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #18 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:ec5cb2a0f2436618219ce0ada3086f6088e37332
commit r13-8452-gec5cb2a0f2436618219ce0ada3086f6088e37332
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109668
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8c4785e77e8b54109fbb4f81a3b624e98184c2aa
commit r13-8449-g8c4785e77e8b54109fbb4f81a3b624e98184c2aa
Author: Sam James
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114211
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:df3994a1be3565ad450d552dc94b696748a7807a
commit r13-8447-gdf3994a1be3565ad450d552dc94b696748a7807a
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114184
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:128860abd58605d616c184a9a68886a25862b2dd
commit r13-8446-g128860abd58605d616c184a9a68886a25862b2dd
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #24 from Jakub Jelinek ---
Created attachment 57714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57714&action=edit
gcc14-pr114175.patch
Untested x86_64 fix.
Given the r13-3549 change, I'd guess most likely aarch64, alpha, ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #5 from JF Bastien ---
(In reply to Andrew Pinski from comment #4)
> (In reply to JF Bastien from comment #3)
> > The LLVM feature was added for XNU, because the kernel never runs its own
> > global C++ destructors (but the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60466
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.1.2, 4.4.7
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57597
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57491
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #4 from Andrew Pinski ---
(In reply to JF Bastien from comment #3)
> The LLVM feature was added for XNU, because the kernel never runs its own
> global C++ destructors (but the compiler can't know this). It saved a
> non-trivial amou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #3 from JF Bastien ---
The LLVM feature was added for XNU, because the kernel never runs its own
global C++ destructors (but the compiler can't know this). It saved a
non-trivial amount of code generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64009
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Summary|C++: Sup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #1 from Andrew Pinski ---
This sounds like a very dangerous attribute to have. It changes behavior and
even could cause memory leaks if abused.
Plus I think it is also designed to get around folks not programming well
defined C++ co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
--- Comment #8 from Andrew Pinski ---
iwmmxt support has been deprecated in GCC 13 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
Bug ID: 114357
Summary: C++: Support the no_destroy attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
Sam James changed:
What|Removed |Added
Target|riscv, loongarch|riscv, loongarch, x86_64
--- Comment #23 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283
Andrew Pinski changed:
What|Removed |Added
Component|fortran |tree-optimization
Status|WAI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #33 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|14.0|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110826
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110826
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:4e9f475cdc8617f94c903656faaf28910c21c29b
commit r13-8445-g4e9f475cdc8617f94c903656faaf28910c21c29b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:337dc58139595bd9ab4101b988078c5d54d8506a
commit r13-8444-g337dc58139595bd9ab4101b988078c5d54d8506a
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #12 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:90442fb421823153c4f762a2d26a0d700af2e6c3
commit r13-8443-g90442fb421823153c4f762a2d26a0d700af2e6c3
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:ba4b4b3864d426835ea10e900a4e1dd466d06e51
commit r13-8442-gba4b4b3864d426835ea10e900a4e1dd466d06e51
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #17 from David Binderman ---
I tried out gcc-13.2 and got the following results:
foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out
checksum = 77A231E6
foundBug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
--- Comment #4 from Peter Bergner ---
The bogus vsx_splat_ code goes all the way back to GCC 8, so we need
backports to the open release branches (GCC 13, 12, 11).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #8)
> (In reply to Mikael Morin from comment #7)
> > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> > Excess errors:
> > /home/mik/gcc/gccx/src/gcc/testsuite/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114324
--- Comment #4 from mjr19 at cam dot ac.uk ---
Created attachment 57713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57713&action=edit
Second testcase, very similar to first
Thank you for looking into this. The real code in question has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #7)
> The changes are these:
>
> PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr101267.f90 -O (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> I need to reevaluate it; there were other regressions if I remember
> correctly.
The changes are these:
PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #5 from Sam James ---
>From my overnight run, just for completeness:
```
struct a {};
template using b = a;
template class, typename, typename> using c = a;
template using d = g;
template constexpr int e(b<1>) { return 1; }
templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111853
--- Comment #4 from Steve Kargl ---
On Thu, Mar 14, 2024 at 09:00:22AM +, fxcoudert at gcc dot gnu.org wrote:
>
> --- Comment #3 from Francois-Xavier Coudert ---
> This seems safe to backport, what do you think?
>
Paul just landed a big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #8 from Andrew Pinski ---
For the non-static case, IPA-SRA has:
```
Summary for node int foo2(two_ints)/0:
Returns value
Descriptor for parameter 0:
param_size_limit: 8, size_reached: 4
* Access to unit offset: 0, unit siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #7 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #6)
> I am think this can be closed as fixed ...
Well, my example no longer generates two loads. However
> IPA-SRA does handle this if the function is static.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114329
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=114327
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114327
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a6dab195f7041671166b9aa6a37e0db4236c829d
commit r14-9498-ga6dab195f7041671166b9aa6a37e0db4236c829d
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
--- Comment #4 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gbwf7l@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114356
Bug ID: 114356
Summary: std::shared_ptr constructor constraints give poor
diagnostics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #8 from Pali Rohár ---
Thank you for input, as you already figured out there is lot of work for this.
And I think I'm not skilled enough to implement everything properly, so I would
have to let this to gcc developers. I will answer q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #16 from David Binderman ---
(In reply to David Binderman from comment #15)
> So it looks like one or more of the --param flags is to blame.
foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out
checksum = 77A231E6
foundBugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #15 from David Binderman ---
(In reply to Jakub Jelinek from comment #14)
> So, that is -O2 -fgcse-after-reload -fipa-cp-clone -floop-interchange
> -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops
> -fsplit-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114355
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114355
Bug ID: 114355
Summary: Segfault passing missing optional dummy of bind(c)
subroutine to optional assumed-rank dummy
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #4 from Joseph S. Myers ---
I think it's correct that conversions (explicit or implicit) from a value with
excess precision convert only once; they don't first remove excess range and
precision and then convert to the target type.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #14 from Jakub Jelinek ---
/* -O3 optimizations. */
{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #13 from David Binderman ---
I had another look at the original source code and got this with
recent gcc trunk:
foundBugs $ ~/gcc/results/bin/gcc -w bug998.c && ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #12 from Richard Biener ---
The second testcase behaves the same with -O0, -O2 and -O3 on x86_64-linux for
me (and with trunk and GCC 13.2.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #22 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ffd47fb63ddc024db847daa07f8ae27fffdfcb28
commit r14-9497-gffd47fb63ddc024db847daa07f8ae27fffdfcb28
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #20)
> Though, trying that in a cross to arm, with -march=armv9-a
> -munaligned-access it matches (in that case I believe vect_hw_misalign
> should be true), but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354
Bug ID: 114354
Summary: std::shared_ptr constructor constraints are checked
too late
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112703
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #20 from Jeffrey A. Law ---
Go right ahead. I'm mostly trying to get things in the right broad buckets.
So if you've got additional information, please add it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #11 from peter0x44 at disroot dot org ---
.I did some digging into why lto-wrapper.cc is emitting these commands
It seems that they are not essential.
/* If we are not preserving the ltrans input files then
truncate them as soon a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] address |[13 Regression] address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107337
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
--- Comment #3 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #2)
> It almost looks like a costing issue. The threaders find opportunities to
> thread all the incoming edges in the key block to the path which avoids the
> call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
using A = struct {};
template class, typename, typename>
using B = A;
template
using C = typename T::D;
struct E {
using D = B;
};
template constexpr bool foo (A) { return false; }
tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114320
--- Comment #2 from Nathaniel Shead ---
Sorry about that. I've not been able to work out what configure flags I need to
pass to cause this to error in the first place (I don't normally develop for
powerpc and the machine I'm using doesn't seem t
1 - 100 of 157 matches
Mail list logo
