https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059
--- Comment #32 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:62ec780ac0b4d109f2a3c8c4597cb19a82f6188d
commit r13-3147-g62ec780ac0b4d109f2a3c8c4597cb19a82f6188d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059
--- Comment #33 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:348e46fa8cba960c23170673bfc0c1b4fb384975
commit r13-3148-g348e46fa8cba960c23170673bfc0c1b4fb384975
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
--- Comment #2 from Richard Biener ---
final value replacement:
b_lsm.8_26 = PHI
with expr: 1
final stmt:
b_lsm.8_26 = 1;
where
(get_scalar_evolution
(scalar = b_lsm.8_15)
(scalar_evolution = {0, +, 1}_1))
(chrec_apply
(varying_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #10 from Richard Biener ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Alexander Monakov from comment #8)
> > We need a solution that works for combine too — is it possible to invent a
> > representation for a no-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #11 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> If we don't want to treat such copies as noop moves, then either we need to
> change rtx_equal_p such that it will say MEMs aren't equal if the the alias
> set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > At least GCC points out the colon and even suggest you started a bitfield
> > which is what a colon normally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107178
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jonathan Wakely from comment #3)You'd need to change "T
> foo():" to "int foo:N" i.e. change the type, remove the parens, and add a
> constant f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107153
--- Comment #2 from Richard Biener ---
OK, so the main issue is that when we parallelize a loop without stores we
insert stores and thus would require a loop PHI for the virtual operand plus
LC SSA updates.
We eventually end up in gen_parallel_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107094
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #23 from Andrew Haley ---
This bug has pernicious effects in many more places:
https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html
Florian is right: at least, GCC should not automatically link crtfastmat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090
--- Comment #4 from vfdff ---
(In reply to Andrew Pinski from comment #1)
> A few issues.
> First is:
>
> if (_26 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870913]:
> ht_15 = ht_13 + 4294967296;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107179
Bug ID: 107179
Summary: requires-expression gives hard error for inaccessible
constructor
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Keywords: rejects-va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #3 from Aldy Hernandez ---
(In reply to Martin Liška from comment #2)
> Started with r13-1268-g8c99e307b20c502e.
Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not
this patch that caused the problem. Fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107153
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:89228e3985c5cdf6be58a3b5b1afcad91e9e3422
commit r13-3161-g89228e3985c5cdf6be58a3b5b1afcad91e9e3422
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107153
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
--- Comment #12 from Alexander Monakov ---
For reference, the previous whacked mole appears to be PR 106187 (where
mems_same_for_tbaa_p comes from).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107179
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104433
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:edbb2551d156d69a2e337dcd8daa69f2680d57ea
commit r13-3163-gedbb2551d156d69a2e337dcd8daa69f2680d57ea
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 104433, which changed state.
Bug 104433 Summary: [modules] Importing and using std::make_shared
causes linker errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104433
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104433
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107180
Bug ID: 107180
Summary: Itanium ABI says to block in the emergency EH buffer
if memory cannot be acquired
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #2 from Jeff Hammond ---
Is this ever going to be fixed? I observe that a similar MCVE (below) is
compiled without complaint by Intel, Cray and NAG Fortran, so it's almost
certainly a lack of support for the standard in GCC.
As best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #14 from Jakub Jelinek ---
Created attachment 53675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53675&action=edit
gcc13-pr106654-gimple-wip.patch
My current WIP patch for the handling of more complex assumptions.
My curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
Martin Liška changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Bug ID: 107181
Summary: new test case gcc.dg/pr25521.c fails in
r13-2952-ga0aafbc324aa90
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
seurer at gcc dot gnu.org changed:
What|Removed |Added
Host||powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Bug ID: 107182
Summary: Commit
r13-2871-g1b74b5cb4e9d7191f298245063a8f9c3a1bbeff4
breaks profiledbootstrap
Product: gcc
Version: 13.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
--- Comment #1 from Franz Sirl ---
Created attachment 53677
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53677&action=edit
Related GCDA file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Jose E. Marchesi changed:
What|Removed |Added
CC||jose.marchesi at oracle dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107173
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #20 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603073.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107173
--- Comment #2 from Esa Pulkkinen ---
Not sure if this info helps reproducing it, but trying to collect info about
the environment. I built gcc-13 from version
basepoints/gcc-13-2397-g20d30e737ad.
% LC_MESSAGES=C /usr/local/bin/g++ -v
Using bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105783
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f09b99550a3c6cd16f5e9150ebd4b1d87033dcbd
commit r13-3168-gf09b99550a3c6cd16f5e9150ebd4b1d87033dcbd
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105783
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97091
Patrick Palka changed:
What|Removed |Added
CC||hasse.christoph at cern dot ch
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 102851, which changed state.
Bug 102851 Summary: Failure to demangle c++ symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #24 from H.J. Lu ---
Dropping crtfastmath.o with -shared makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |rtl-optimization
Summary|Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181
Andrew Pinski changed:
What|Removed |Added
Component|testsuite |target
--- Comment #3 from Andrew Pinsk
, trunk outputs:
13.0.0 20221007
Z4mainEUlDpT_E_
-> main::{lambda((auto:1)...)#1}
So I suppose this can be resolved as fixed for GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107173
--- Comment #3 from Esa Pulkkinen ---
I realize also -E option is necessary for the problem. I tried various flags to
enable/disable modules support (e.g. -fmodules-ts), but those seem not to
impact the problem, though they impact what happens i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #42 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:b9ad850e86b863c24f6f4f5acf08d49944cc7bbe
commit r13-3171-gb9ad850e86b863c24f6f4f5acf08d49944cc7bbe
Author: Qing Zhao
Date: Fri Oct
tdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-3161-20221007142737-g89228e3985c-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221007 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Siddhesh Poyarekar changed:
What|Removed |Added
Summary|[13 Regression] Bogus |Bogus -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
--- Comment #8 from Siddhesh Poyarekar ---
I forgot to mention that I've been building with:
gcc/cc1 -o /dev/null ../bogus-stringop-overflow.i -O2 -Werror=stringop-overflow
-quiet
to reproduce the warning:
../bogus-stringop-overflow.i: In fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038
Siddhesh Poyarekar changed:
What|Removed |Added
Last reconfirmed||2022-10-07
Version|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100134
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #5 from Steve Kargl ---
On Fri, Oct 07, 2022 at 07:15:59PM +, anlauf at gcc dot gnu.org wrote:
>
> @Steve: I thought there is something in the standard that says how the
> resolution (specific then generic) works, but cannot find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> Both match type "integer", kind "4", rank "0".
>
> AFAIK, there is no other consideration than TKR to discern which function
> to call.
Yes, assuming t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Andrew Pinski changed:
What|Removed |Added
Component|debug |target
Summary|-fcompare-deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #8 from Steve Kargl ---
On Fri, Oct 07, 2022 at 08:42:51PM +, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
>
> Mikael Morin changed:
>
>What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #9 from Mikael Morin ---
(In reply to Jeff Hammond from comment #2)
>
> My MCVE:
>
> module f
> implicit none
>
> interface test
> module procedure test_f08
> module procedure test_f08ts
> end interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #7)
> I think it's in 15.4.3.4.5 Restrictions on generic declarations.
> But it's too late for me to decipher what's written there.
Tomorrow you'll discover
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107182
--- Comment #3 from Jeffrey A. Law ---
Testing a trivial patch now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:895dd027d5dda51a95d242aec8a49a6dfa5db58d
commit r13-3173-g895dd027d5dda51a95d242aec8a49a6dfa5db58d
Author: Marek Polacek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107085
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #5 from H.J. Lu ---
i386 needs to change
(ltu:SI (const_int 1 [1])
(const_int 0 [0]))
to
(ne:SI (const_int 1 [1])
(const_int 0 [0]))
when checking the carry flag. But the mode info isn't passed to
TARGET_CANONICALIZE_COM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100603
Jan-Benedict Glaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #11 from Kees Cook ---
(In reply to Richard Biener from comment #10)
> I sofar refrained from doing this because of the large amount of fallout and
> followup changes and I think those are not warranted on the GCC 12 branch.
Totally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409
--- Comment #11 from Jeff Hammond ---
> program foo
>use f
>integer i
>call test(i)
> end program
>
> which specific subroutine is called based on TKR?
I understand there is an ambiguity here, but what if I never make this call?
Is
69 matches
Mail list logo