https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472
--- Comment #5 from Richard Biener ---
On the GCC 11 branch head I cannot reproduce this with a x86_64-linux ->
m68k-linux cross cc1, using -O2 -fwrapv -fPIC -g2 -Wno-unused-result
-Wsign-compare -Wall
Can you clarify that it is the compiler th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #16 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:204f56aa65d2496e9f7db86c4aa37d42a336fc5b
commit r12-3877-g204f56aa65d2496e9f7db86c4aa37d42a336fc5b
Author: Tobias Burnus
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see
> a domain crossing penalty here(?). But since this is a generic arch/tuning
> regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
--- Comment #10 from Antony Polukhin ---
Any progress?
Multiple compilers already eliminate the atexit call. Moreover, some of the
compilers even eliminate the guard variable after that
https://godbolt.org/z/dbdfMrroa
Note that the atexit elim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726
Richard Biener changed:
What|Removed |Added
Known to work||10.3.0, 11.2.1, 7.5.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
: verify_gimple failed
0xdac31a verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.c:5576
$ /home/dcb/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20210924/libexec/gcc/x86_64-pc-linux-g
nu/12.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102475
Bug ID: 102475
Summary: incorrect definition of "normal" long doubles in
libgcc/config/rs6000/ibm-ldouble-format
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017
--- Comment #3 from Christophe Lyon ---
I made a typo in my description of the bug, it should read: fenv support is NOW
enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102476
Bug ID: 102476
Summary: d: Options -fmain and -fno-druntime do not work
together
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
//binary-trunk-r12-3878-20210924101619-g710c6ab4ad5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210924 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
rdapp at linux dot ibm.com changed:
What|Removed |Added
CC||rdapp at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464
--- Comment #5 from Hongtao.liu ---
(gdb) p direct_internal_fn_supported_p (IFN_CEIL, type, OPTIMIZE_FOR_BOTH)
$110 = false
(gdb) p direct_internal_fn_supported_p (IFN_SQRT, type, OPTIMIZE_FOR_BOTH)
$111 = true
hmm, why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464
--- Comment #6 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #5)
> (gdb) p direct_internal_fn_supported_p (IFN_CEIL, type, OPTIMIZE_FOR_BOTH)
> $110 = false
>
> (gdb) p direct_internal_fn_supported_p (IFN_SQRT, type, OPTIMIZE_FOR_B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #4 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> (In reply to Richard Biener from comment #1)
> > Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see
> > a domain crossing penalty here(?).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-09-24
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102442
Joseph C. Sible changed:
What|Removed |Added
CC||josephcsible at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
--- Comment #5 from rdapp at linux dot ibm.com ---
git bisect bad5f6a6c91d7c592cb49f7c519f289777eac09bb74 is the first bad commit
commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74
Author: Richard Earnshaw
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147
--- Comment #8 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:51ca05031959d3accffe873e87d4bc4fbd22e9e9
commit r12-3881-g51ca05031959d3accffe873e87d4bc4fbd22e9e9
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
--- Comment #6 from Richard Earnshaw ---
So I think we need a way of checking that this won't fail before we call it.
Any idea?
tree type = lang_hooks.types.type_for_size (ilen * 8, 1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
--- Comment #7 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #6)
> So I think we need a way of checking that this won't fail before we call it.
>
> Any idea?
>
> tree type = lang_hooks.types.type_for_size (il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
--- Comment #2 from Bill Schmidt ---
Patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580235.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
--- Comment #8 from Richard Earnshaw ---
I suspect go has a similar issue, but it looks as though c, c++, fortran and d
are all ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #4 from Patrick Palka ---
And if -(1) is to be mangled the same as -1, then shouldn't
template
typename std::enable_if<(int)sizeof(T) >= -(1), int>::type size1(T *t);
template
typename std::enable_if<(int)sizeof(T) >= -1, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:34947d4e97ee72b26491cfe5ff4fa8258fadbe95
commit r12-3882-g34947d4e97ee72b26491cfe5ff4fa8258fadbe95
Author: Patrick Palka
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:34947d4e97ee72b26491cfe5ff4fa8258fadbe95
commit r12-3882-g34947d4e97ee72b26491cfe5ff4fa8258fadbe95
Author: Patrick Palka
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333
--- Comment #1 from CVS Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:2364250eccc389a5f9820ac55f8260d34f229e73
commit r12-3883-g2364250eccc389a5f9820ac55f8260d34f229e73
Author: Sandra Loosemore
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458
--- Comment #11 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:84cccff60a978174271a30042bf7841d2ae436eb
commit r12-3884-g84cccff60a978174271a30042bf7841d2ae436eb
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
--- Comment #3 from Jakub Jelinek ---
Perhaps we need something like:
--- gcc/var-tracking.c.jj 2021-05-04 21:02:24.196799586 +0200
+++ gcc/var-tracking.c 2021-09-24 19:23:16.420154828 +0200
@@ -6133,7 +6133,9 @@ add_stores (rtx loc, cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #15 from David Binderman ---
Since this bug depends on the setting of -march,
I tried out all the possible legal settings of that value.
alderlake
amdfam10
during GIMPLE pass: aprefetch
athlon-fx
during GIMPLE pass: aprefetch
athlon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84501
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500
--- Comment #3 from Andrew Pinski ---
We get in GCC 10+ (r10-464-ga9c697b88395a, same revision which fixed PR 84501):
:4:18: warning: initializer-string for array of 'int' is too long
4 | wchar_t w[3] = L"abcd";
| ^~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500
--- Comment #4 from Jonathan Wakely ---
Well Martin suggested it should include the array length, but I'm content with
not saying "chars".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500
--- Comment #5 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> Well Martin suggested it should include the array length, but I'm content
> with not saying "chars".
What is interesting is the C++ front-end with that change
s: zlib zstd
gcc version 12.0.0 20210924 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #2 from Kees Cook ---
Note that this needs a struct attribute that will allow structs to be excluded
from the diagnostic (since the kernel needs to deal with legacy UAPI headers
forever).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102478
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
Emmanuel Le Trong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #7 from Richard Smith ---
(In reply to Patrick Palka from comment #3)
> Hmm, but according to
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.literal the
> mangling of a negative integer literal is prefixed with "n",
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472
Giulio Benetti changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447
--- Comment #2 from Jonathan Wakely ---
Actually, this might not be a bug.
We have this comment in regex_compiler.tcc
// POSIX doesn't allow '-' as a start-range char (say [a-z--0]),
// except when the '-' is the first or last char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102479
Bug ID: 102479
Summary: segfault when deducing class template arguments for
tuple with libc++-14
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102479
--- Comment #1 from Kent Ross ---
The error also occurs in c++20 and c++17 modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #3 from Segher Boessenkool ---
(In reply to Martin Sebor from comment #1)
> With the introduction of -Wzero-length-bounds in GCC 10 (which,
> incidentally, was added specifically to ease the adoption of the stricter
> array bounds che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
Bug ID: 102480
Summary: std::regex fails to match ^ when match_prev_avail is
used
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-09-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88822
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102442
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
Andrew Pinski changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102049
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102481
Bug ID: 102481
Summary: Incorrect source file path in debuginfo for assembly
file specified with relative path
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102481
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
68 matches
Mail list logo
