https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103443
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:cc56c03a7a7f034f98a835dcb7047ad3d2ace6bd
commit r10-10304-gcc56c03a7a7f034f98a835dcb7047ad3d2ace6bd
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:cc56c03a7a7f034f98a835dcb7047ad3d2ace6bd
commit r10-10304-gcc56c03a7a7f034f98a835dcb7047ad3d2ace6bd
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101583
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
commit r10-10305-g5c86e63cb0383a38ec3dea24e9b3fe2f6e312057
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b3f135a50c3dd7fc04252e17d7fbb08ca95aa9a5
commit r10-10307-gb3f135a50c3dd7fc04252e17d7fbb08ca95aa9a5
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:923637b6cb70986e83ae0109ec4bcd26fdfe3624
commit r10-10308-g923637b6cb70986e83ae0109ec4bcd26fdfe3624
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101965
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:30033d9bb9d5e5303fadf448999f4f27e2693ed6
commit r10-10309-g30033d9bb9d5e5303fadf448999f4f27e2693ed6
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:0d480b8403f2541402adeed82deb7eb028330b87
commit r10-10310-g0d480b8403f2541402adeed82deb7eb028330b87
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
--- Comment #5 from cqwrteur ---
(In reply to Eric Gallager from comment #4)
> This is affecting The Battle for Wesnoth:
> https://github.com/wesnoth/wesnoth/issues/6291
C++ std::regex is just terrible and highly likely be deprecated in the futu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102270
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102894
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #17 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #16)
> ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> target as both input and output, it seems we can't create a new target for
> that.
O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
--- Comment #18 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Hongtao.liu from comment #16)
>
> > ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> > target as both input and output, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103020
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101965
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102431
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.4|11.3
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|11.3|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #6 from Martin Jambor ---
Created attachment 51884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51884&action=edit
Untested fix
I am testing this fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #22 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8d3391d64799d490117ad48432a9ad2cf38b0091
commit r11-9317-g8d3391d64799d490117ad48432a9ad2cf38b0091
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|10.4
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45365
Roger Sayle changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96159
--- Comment #9 from Martin Uecker ---
Yes the clang behavior is useful.
If we get the optimal code for types with sufficient alignment, then I do not
think a separate set of functions would be required. A programmer simply can
use the _Atomi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103442
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #7 from Andrew Pinski ---
*** Bug 103442 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
Bug ID: 103444
Summary: Fortran async IO is broken on FreeBSD
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
--- Comment #1 from kargl at gcc dot gnu.org ---
=== libgomp Summary ===
# of expected passes7743
# of unexpected failures31
# of expected failures 72
# of unsupported tests 227
Each of as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103444
--- Comment #2 from kargl at gcc dot gnu.org ---
% gfcx -o z -fopenmp -g async_io_1.f90
% gdb ./z
(gdb) run
Starting program: /home/kargl/tmp/z
[New LWP 118209 of process 77440]
Thread 2 received signal SIGBUS, Bus error.
[Switching to LWP 1182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #9 from Steve Kargl ---
On Thu, Nov 25, 2021 at 10:10:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> Unfortunately the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716
Klaus Rudolph changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435
Klaus Rudolph changed:
What|Removed |Added
CC||lts-rudolph at gmx dot de
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
Bug ID: 103445
Summary: build failure for old versions of mingw32 (not
mingw-w64)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #9)
> "does not work for me" isn't too descriptive.
Well, you fixed a related issue, but not the problem in comment#0.
Try your patch on:
module m
contain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:376b2c781d11f55644e92dfea91c3f214f20f4ac
commit r10-10311-g376b2c781d11f55644e92dfea91c3f214f20f4ac
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:dd1871c823e2ec9a500ac5ad3c87a117b934fa3b
commit r9-9846-gdd1871c823e2ec9a500ac5ad3c87a117b934fa3b
Author: Harald Anlauf
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #1 from Jonathan Wakely ---
How old is that? We generally only support building with recent versions that
are still supported by mingw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #2 from cqwrteur ---
(In reply to Jonathan Wakely from comment #1)
> How old is that? We generally only support building with recent versions
> that are still supported by MinGW.
dev C++'s mingw.
that is mingw-w64. not mingw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716
Andrew Pinski changed:
What|Removed |Added
Summary|variadic template multiple |[10/11 Regression] variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #3 from cqwrteur ---
(In reply to cqwrteur from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > How old is that? We generally only support building with recent versions
> > that are still supported by MinGW.
>
> dev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787
--- Comment #8 from anlauf at gcc dot gnu.org ---
Simpler and better patch which handles array sections as well as vector
subscripts:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..f870c225195 100644
--- a/gcc/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103438
--- Comment #8 from Nils Smeds ---
(In reply to Nils Smeds from comment #7)
> (In reply to Martin Liška from comment #6)
> > Lemme take a look.
>
> Great, thanks.
prefetch-loop-arrays appears to be activated on arm,s390 and i386 at level -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103445
--- Comment #4 from Jonathan Wakely ---
Sorry, I don't understand anything above. I don't care whether you're using
mingw or mingw-w64, what I asked is how old it is. Libstdc++ expects a recent
version, and I'm not surprised if it doesn't work w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:4d540c7a4a7fb87b04d06e1ee7f9b004116279a4
commit r12-5550-g4d540c7a4a7fb87b04d06e1ee7f9b004116279a4
Author: Harald Anlauf
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
--- Comment #11 from Steve Kargl ---
On Fri, Nov 26, 2021 at 08:13:05PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
>
> --- Comment #10 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Ka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
--- Comment #8 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #6)
> Then no change matching "g++.dg/modules/xtreme-" up to and including
> a29174904bb1 (r12-5240), which is the last run at this writing.
Update:
At 6ea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439
--- Comment #5 from Andrew Pinski ---
(In reply to Richard Biener from comment #4)
> so quite hard if not impossible to "fix" in genemit
The most complex one I saw in action was mod3 in aarch64.md:
(define_expand "mod3"
[(match_operand:GPI 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84693
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
Bug ID: 103446
Summary: Invalid wide multibyte character constant
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #1 from Zloten ---
56481 = 0xDCA1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #2 from Andrew Pinski ---
Is there a full testcase including what options you used?
Did you use "-finput-charset=" and -fexec-charset= options?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103432
--- Comment #6 from Sergei Trofimovich ---
(In reply to Jan Hubicka from comment #4)
> Fixed on trunk by g:a70faf6e4df7481c2c9a08a06657c20beb3043de (sorry for
> cut&pasting wrong PR number).
Tested on full libjxl-0.5 testsuite. All works now. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:76c6be48b7841524974754f8ea7533b82c7de77e
commit r12-5551-g76c6be48b7841524974754f8ea7533b82c7de77e
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #3 from Zloten ---
No. Just - O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #4 from Andrew Pinski ---
What target and what is the host?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
--- Comment #5 from Zloten ---
I use the latest MinGW, target-host are Windows, x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103446
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103441
--- Comment #8 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:9e2e47391b316493b52fbb47b4b992b0863795dd
commit r12-5554-g9e2e47391b316493b52fbb47b4b992b0863795dd
Author: Martin Jambor
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
Bug ID: 103447
Summary: left shift operator gives wrong result for shift of 48
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
--- Comment #2 from Greg Morse ---
Thanks for the v. quick reply. I feel like an idiot.G. M.
On Friday, November 26, 2021, 04:13:45 p.m. PST, pinskia at gcc dot gnu.org
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103447
And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2021-11-27
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
Bug ID: 103448
Summary: unexpected tuple collapse
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #1 from Andrew Pinski ---
Hmm, even clang with libc++ produces the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #2 from Janez Zemva ---
I have no idea, but it seems wrong me. Is there an explanation for the lvalue
references? I expected rvalue references, but that's unrelated to the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #4 from Janez Zemva ---
Ok, thank you :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Yes it is called the copy (or move) constructor :).
That is:
auto t = std::tuple(std::tuple(1,2));
std::cout << type_name() << std::endl;
Will produce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > Yes it is called the copy (or move) constructor :).
>
> That is:
> auto t = std::tuple(std::tuple(1,2));
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #7 from Janez Zemva ---
The c++17 type deduction rules are also going on. This makes me wonder how
std::make_tuple() circumvents the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103448
--- Comment #8 from Andrew Pinski ---
(In reply to Janez Zemva from comment #7)
> The c++17 type deduction rules are also going on. This makes me wonder how
> std::make_tuple() circumvents the problem.
Easy, it does not use the C++17 deduction
101 - 176 of 176 matches
Mail list logo
