https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
--- Comment #3 from Fangrui Song ---
(In reply to Andrew Pinski from comment #2)
> GCC added -fdebug-prefix-map= back in r0-82686-gc8aea42ce2c691e4e8 2 years
> before clang was first release . So
Thank you for the super rapid response!
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179
--- Comment #7 from Jason Merrill ---
(In reply to stu t from comment #6)
> Thank you for looking into this! :)
You're welcome! I'm currently leaning toward backporting this to 12.4 rather
than 12.3, but am interested in your thoughts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:9ab083eb8a96b7f8baf6fe632d03aa496017e456
commit r11-10647-g9ab083eb8a96b7f8baf6fe632d03aa496017e456
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:b6c8048cdd2c1e523f663f248ba39caed5af90e7
commit r11-10646-gb6c8048cdd2c1e523f663f248ba39caed5af90e7
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #16 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:51738bb097444dd3ca7adcfa28ae8dcff5a14c50
commit r11-10645-g51738bb097444dd3ca7adcfa28ae8dcff5a14c50
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:691e385b354482f3379bba471774873ca7179b79
commit r11-10643-g691e385b354482f3379bba471774873ca7179b79
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105406
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:657fb0db2648a8cd7ba355fdec570fe2f08448ac
commit r11-10642-g657fb0db2648a8cd7ba355fdec570fe2f08448ac
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410
--- Comment #15 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:fbf72bbaed4477f1e3881a8d25977dd3890015eb
commit r11-10644-gfbf72bbaed4477f1e3881a8d25977dd3890015eb
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
--- Comment #24 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:998e77e55126269b3e67b2f05f0f27a421839673
commit r11-10641-g998e77e55126269b3e67b2f05f0f27a421839673
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
--- Comment #21 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:998e77e55126269b3e67b2f05f0f27a421839673
commit r11-10641-g998e77e55126269b3e67b2f05f0f27a421839673
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:469881efc4ad365dce3db26dab7d33f95d36f92f
commit r11-10640-g469881efc4ad365dce3db26dab7d33f95d36f92f
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #10 from Jeffrey A. Law ---
The sign_extend later gets turned into zero_extend. Presumably because we know
the value is never negative. That in and of itself wouldn't be a big deal as
it should be easily recognizable using any_exte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
Bug ID: 109592
Summary: Failure to recognize shifts as sign/zero extension
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #9 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #6)
> Comment on attachment 54905 [details]
> proposed patch
>
> So that's a subset of what we've done. We initially thought that was going
> to be enough to solve t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109580
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-04-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
--- Comment #2 from Andrew Pinski ---
GCC added -fdebug-prefix-map= back in r0-82686-gc8aea42ce2c691e4e8 2 years
before clang was first release . So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
--- Comment #1 from Andrew Pinski ---
>When multiple -fdebug-prefix-map= options are applicable, it seems that the
>last wins.
Right, that is the standard way all options in GCC works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
Bug ID: 109591
Summary: Multiple -fdebug-prefix-map= prefixes match, which one
wins?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #8 from Jeffrey A. Law ---
So coming back to this after a couple months, I'm confident the match.pd change
is unnecessary and in fact wrong. So we definitely want to set that aside.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
--- Comment #3 from Steve Kargl ---
On Fri, Apr 21, 2023 at 08:24:45PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> I have some idea how (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #7 from Vineet Gupta ---
(In reply to Roger Sayle from comment #5)
> Created attachment 54905 [details]
> proposed patch
>
> This patch should fix this problem, by adding another pattern the machine
> description to also recognize z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590
--- Comment #2 from Jonny Grant ---
(In reply to Andrew Pinski from comment #1)
> There is -Wnull-dereference for this ...
I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to
get enabled by -Wall -Wextra)
I just expect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590
--- Comment #1 from Andrew Pinski ---
There is -Wnull-dereference for this ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590
Bug ID: 109590
Summary: array-bounds does not warn about address 0x0
dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108795
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:1c1a9a0b60a9a182bcff79084e5ac367a6329bc2
commit r12-9463-g1c1a9a0b60a9a182bcff79084e5ac367a6329bc2
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
--- Comment #5 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:f828503eeb79ad1f1ada6db7deccc5abcc2f3ca3
commit r14-160-gf828503eeb79ad1f1ada6db7deccc5abcc2f3ca3
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:e81e393cd864abcd2de02602bd51e435dc28f418
commit r10-11307-ge81e393cd864abcd2de02602bd51e435dc28f418
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:92e2bb31ffe25271e5ae70d7533469419b883864
commit r10-11305-g92e2bb31ffe25271e5ae70d7533469419b883864
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:da17a9049ee0a8ca9f93edf137df92e824a7593e
commit r10-11306-gda17a9049ee0a8ca9f93edf137df92e824a7593e
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410
--- Comment #14 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:fc03893d2fead133ed336511ac00d75c10c5a88d
commit r10-11304-gfc03893d2fead133ed336511ac00d75c10c5a88d
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:6f7f90113bc78440a248bef4b917583fde3e6e5f
commit r10-11303-g6f7f90113bc78440a248bef4b917583fde3e6e5f
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
--- Comment #2 from Andrew Pinski ---
At -O2 we get:
size: 26-3, last_iteration: 2-2
Loop size: 26
Estimated size after unrolling: 245
Not unrolling loop 1: size would grow.
With -O3:
size: 20-4, last_iteration: 2-2
Loop size: 20
Esti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
--- Comment #2 from anlauf at gcc dot gnu.org ---
I have some idea how (and where) the runtime checks need to be implemented,
but I am confused by the following observations on the occurence of an
explicit RETURN statement and the use of a RESULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Andrew Pinski changed:
What|Removed |Added
Keywords|ra |
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893
Jason Merrill changed:
What|Removed |Added
Known to work||12.3.0, 13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
--- Comment #6 from Georg-Johann Lay ---
(In reply to Roger Sayle from comment #5)
> This is now fixed on mainline [but was present in GCC 12.2], and a new test
> case added to ensure this stays fixed.
Hi Roger,
I am having a problem with your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #26 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:03cebd304955a6b9c5607e09312d77f1307cc98e
commit r14-159-g03cebd304955a6b9c5607e09312d77f1307cc98e
Author: Jason Merrill
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
--- Comment #4 from Andrew Macleod ---
And I think the first part of this is a duplicate of another PR from GCC12
time (I dont know which one) whereby we are not making staticly initialized
values available in main(). so VRP never sees that d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
--- Comment #3 from Andrew Macleod ---
Patch in testing.
when deciding to fold condition of builtin_unreachable, VRP is failing to
recognize that given
if (ptr == &x)
__builtin_unreachable ()
&x is not a representable range, and thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
--- Comment #2 from Andrew Macleod ---
*** Bug 109588 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:f1f18198b069f461155191ecba41bc87bf5689dd
commit r14-156-gf1f18198b069f461155191ecba41bc87bf5689dd
Author: Jeff Law
Date: Fri Apr 21 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589
--- Comment #2 from Jakub Jelinek ---
Untested workaround, going to test it momentarily:
2023-04-21 Jakub Jelinek
PR bootstrap/109589
* system.h (class auto_mpz): Workaround PR62101 bug in GCC 4.8 and 4.9.
* realmpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last reconfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Mileston
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779
--- Comment #9 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:573624ec90c80d1a024ab405e2575785b869a833
commit r14-154-g573624ec90c80d1a024ab405e2575785b869a833
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:f824216cdb078ea9de0980ae066a0e1e83494fd2
commit r14-153-gf824216cdb078ea9de0980ae066a0e1e83494fd2
Author: Kyrylo Tkachov
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #6 from Jeffrey A. Law ---
Comment on attachment 54905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905
proposed patch
So that's a subset of what we've done. We initially thought that was going to
be enough to solve this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #5 from Roger Sayle ---
Created attachment 54905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905&action=edit
proposed patch
This patch should fix this problem, by adding another pattern the machine
description to also rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
Andrew Pinski changed:
What|Removed |Added
Summary|Carla/sord miscompiled with |Carla/sord miscompiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #11 from Hector Martin ---
Giving a nonzero size to the `ZixBTreeIterFrame stack[]` member also avoids the
segfault, so this might be a flexible array member thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #10 from Andrew Pinski ---
If I change zix_btree_iter_is_end to:
ZIX_API bool
zix_btree_iter_is_end(const struct ZixBTreeIterImpl* const i)
{
if (!i)
return 1;
if (i->stack[0].node == NULL)
return 1;
return 0;
}
Then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #9 from Hector Martin ---
Yes, a strict aliasing violation could explain the behavior of the optimizer
here... but given all the types are identical and there is no casting going on,
clearly there is no strict aliasing violation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #8 from Andrew Pinski ---
Interesting compiling with the C++ front-end (with one minor change of adding a
cast to the malloc) does not seg fault at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #7 from Andrew Pinski ---
-fno-strict-aliasing also fixes the issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #6 from Hector Martin ---
Cleaned it up into a self-contained repro. Simply compiling with `gcc -O2 -o
test test.c && test` gives a segfault. -O1 or -fno-schedule-insns
-fno-schedule-insns2 avoids the issue.
Looking at assembly outp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #5 from Hector Martin ---
Created attachment 54904
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54904&action=edit
self-contained reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589
Bug ID: 109589
Summary: [14 regression] r14-35-g278f8f567b5470 breaks build
with older gcc build compilers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.0|12.3
--- Comment #18 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
--- Comment #14 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8caf5805ad76125b84430b8653003f4776489d46
commit r12-9462-g8caf5805ad76125b84430b8653003f4776489d46
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
--- Comment #17 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8caf5805ad76125b84430b8653003f4776489d46
commit r12-9462-g8caf5805ad76125b84430b8653003f4776489d46
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588
Marek Polacek changed:
What|Removed |Added
Component|c |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by John David Anglin
:
https://gcc.gnu.org/g:dca9419cc3844d3cf3c06f51d5ca57e3b5f50920
commit r12-9461-gdca9419cc3844d3cf3c06f51d5ca57e3b5f50920
Author: John David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588
Bug ID: 109588
Summary: [13 Regression] Missed Dead Code Elimination when
using __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #9 from Francois-Xavier Coudert ---
Present in gcc-13.1.0-RC-20230421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a7e1ee39e4fa37d005929c4ff9457d1a199559c6
commit r14-140-ga7e1ee39e4fa37d005929c4ff9457d1a199559c6
Author: Gaius Mulley
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Bug ID: 109587
Summary: Deeply nested loop unrolling overwhelms register
allocator
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cddfe6bc40b3dc0806e260bbfb4cac82d609a258
commit r14-139-gcddfe6bc40b3dc0806e260bbfb4cac82d609a258
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #4 from Hector Martin ---
This whole codebase is complex, and the problem is in btree code which is hard
to simplify down. Best I can do right now is this. First grab the lv2.tar.gz
attachment and extract it into /tmp. Then:
$ git c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #3 from Hector Martin ---
Created attachment 54903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54903&action=edit
lv2 plugin bundle for testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586
--- Comment #2 from Gaius Mulley ---
Created attachment 54902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54902&action=edit
Add missing constant type to m2tree_IsAConstant
The function m2block_RememberConstant calls m2tree_IsAConstant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|14.0|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586
Bug ID: 109586
Summary: cc1gm2 ICE when compiling large source file
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #14 from m.cencora at gmail dot com ---
Yeah, in CWG issue comments it is much more clear - but I cannot find such a
wording in C++ latest draft.
English is not my native language so this one is on me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #2 from Richard Biener ---
I wonder if you can provide a harness exercising this at runtime?
Can you try -fno-schedule-insns -fno-schedule-insns2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #13 from Jonathan Wakely ---
And that's clearly the committee's intent:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#302
"Zero the object, then call the default generated constructor" ... "Zero first,
and generate t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #12 from Jonathan Wakely ---
I don't see any ambiguity:
"otherwise, the object is zero-initialized and the semantic constraints for
default-initialization are checked, **and** if T has a non-trivial default
constructor, the object i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #1 from Hector Martin ---
Created attachment 54901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54901&action=edit
Preprocessed input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
Bug ID: 109585
Summary: Carla/sord miscompiled with -O2 on ARM64 (inlining
issue)
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109582
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584
--- Comment #3 from Richard Biener ---
I'm curious what it keys on here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270
--- Comment #2 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:d06e9264b0192c2c77e07d7fb0fe090efcb510c0
commit r14-135-gd06e9264b0192c2c77e07d7fb0fe090efcb510c0
Author: Juzhe-Zhong
Date: Fri Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
--- Comment #11 from m.cencora at gmail dot com ---
Nvm, I understood this rule differently. You are saying that initialization is
two step:
- first zero-initialized,
- then default-initialized.
For me the way this rule is written is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109582
--- Comment #1 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:98d66b204932e343bbf940990914b949e8fccbd5
commit r14-134-g98d66b204932e343bbf940990914b949e8fccbd5
Author: Robin Dapp
Date: Fri Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
Georg-Johann Lay changed:
What|Removed |Added
Attachment #53561|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584
--- Comment #2 from Jonathan Wakely ---
Why is that a GCC bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #2 from Sebastian Huber ---
Sorry for the confusion, the actual bad commit was the follow up commit (NOT
d75be7e4343f049176546aa9517d570e5eb67954):
commit 6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584
--- Comment #1 from cqwrteur ---
Created attachment 54898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54898&action=edit
An example
Example 360 deletes programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584
Bug ID: 109584
Summary: Chinese Antimalware software Qihoo 360 delete entire
GCC install and all programs compiled with GCC
Product: gcc
Version: unknown
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728
--- Comment #3 from CVS Commits ---
The master branch has been updated by HaoChen Gui :
https://gcc.gnu.org/g:6afa7d31a0e8865e17b317ada5cc5014b5d07da3
commit r14-133-g6afa7d31a0e8865e17b317ada5cc5014b5d07da3
Author: Haochen Gui
Date: Fri Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728
--- Comment #2 from CVS Commits ---
The master branch has been updated by HaoChen Gui :
https://gcc.gnu.org/g:4dca6024fb8254117bc1b0ea005a92ee6a7b84be
commit r14-132-g4dca6024fb8254117bc1b0ea005a92ee6a7b84be
Author: Haochen Gui
Date: Fri Ap
1 - 100 of 114 matches
Mail list logo
