https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #10 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:9bacd7af2e3bba9ddad17e7de4e2d299419d819d
commit r12-7167-g9bacd7af2e3bba9ddad17e7de4e2d299419d819d
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104345
--- Comment #11 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:6d98e83b2c919bd9fba2c61333d613bafc37357f
commit r12-7168-g6d98e83b2c919bd9fba2c61333d613bafc37357f
Author: Roger Sayle
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
--- Comment #4 from Richard Biener ---
Bah, what stupid cut&paste error ...
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index d434446a997..3e8d2455ba5 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -2420,12 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
Bug ID: 104480
Summary: [trunk] Combining stores across memory locations might
violate [intro.memory]/3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60712
Richard Biener changed:
What|Removed |Added
Summary|"restrict" qualifier|"restrict" qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
--- Comment #5 from Richard Biener ---
So yes, __restrict info _does_ survive inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104470
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-02-10
Keywords|needs-red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
Bug ID: 104481
Summary: gcc.target/i386/pr35513-8.c and
g++.target/i386/pr35513-[12].C testsuire failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104479
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> Confirmed. When uncond_op is expensive (there's *div amongst them) that's
> definitely unwanted. OTOH when it is cheap then combining will reduce
> latency.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104329
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:9694f6121982668285a21020b55b44c3099f7042
commit r12-7169-g9694f6121982668285a21020b55b44c3099f7042
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104479
--- Comment #3 from rguenther at suse dot de ---
On Thu, 10 Feb 2022, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104479
>
> --- Comment #2 from Hongtao.liu ---
> (In reply to Richard Biener from comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
--- Comment #6 from Richard Biener ---
The typos have been there and unnoticed since the original r5-5305 ... :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104482
Bug ID: 104482
Summary: ICE: Segmentation fault (in
rs6000_builtin_type_compatible), or ICE: tree check:
expected class 'type', have 'reference'
(attr_addr_expr) i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #2 from Uroš Bizjak ---
spawn -ignore SIGHUP /hdd/uros/gcc-build-fast/gcc/xgcc
-B/hdd/uros/gcc-build-fast/gcc/ -fdiagnostics-plain-output -mx32 -O2 -fno-pic
-fexceptions -fasynchronous-unwind-tables -mno-direct-extern-access
-ffat-lt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
Richard Biener changed:
What|Removed |Added
Version|unknown |12.0
--- Comment #2 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #4 from Uroš Bizjak ---
(In reply to Richard Biener from comment #3)
> I'm also seeing those with GNU ld (GNU Binutils; SUSE Linux Enterprise 15)
> 2.37.20211103-7.26
Here with:
$ ld --version
GNU ld version 2.35-18.fc33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104467
--- Comment #3 from Richard Biener ---
Also ICEs with -mavx instead of -mxop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #5 from Uroš Bizjak ---
-save-temps needs to be added to dg-options to cure the UNRESOLVED part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> I don't think [intro.memory]/3
https://eel.is/c++draft/intro.memory
The only thing this mentions is:
Two or more threads of execution can access separate me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #6 from Hongtao.liu ---
The new added GNU_PROPERTY_1_NEEDED is supported in binutils 2.38.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
--- Comment #7 from Marc Poulhiès ---
Thanks !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #9 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:5b2d679bbbcc2b976c6e228ba63afdf67c33164e
commit r12-7170-g5b2d679bbbcc2b976c6e228ba63afdf67c33164e
Author: Tom de Vries
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #7 from Hongtao.liu ---
I think we need dg-require efficient target for those testcases, something like
check_effective_target_pie_copyreloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104467
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104474
Andrew Pinski changed:
What|Removed |Added
Known to fail|12.0|11.2.1
Known to work|11.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88050
felix changed:
What|Removed |Added
CC||felix.von.s at posteo dot de
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Richard Biener changed:
What|Removed |Added
CC|richard.guenther at gmail dot com |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104483
Bug ID: 104483
Summary: Multiplication of huge and small numbers
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855
--- Comment #10 from Jonathan Wakely ---
Ville brought a related case to my attention. With Glibc this compiles, and
finds libc's ::sqrt(double)
#include
int i = sqrt(0);
But on Solaris it doesn't even compile. Solaris libc provides all three
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104483
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1b72d456b2a88218ed440655ef0b9e29b4ef63a9
commit r12-7173-g1b72d456b2a88218ed440655ef0b9e29b4ef63a9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104467
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4a8083285c3edf50088a095870b217ab0881dff0
commit r12-7174-g4a8083285c3edf50088a095870b217ab0881dff0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104466
Richard Biener changed:
What|Removed |Added
Known to work||12.0
--- Comment #8 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104467
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104483
--- Comment #2 from Prof.Dr. Selçuk Han AYDIN ---
In this case, non of the precision gives correct answer when compared with
wxMaxima, Maple, Mathematica or some other wide range precision calculator. Is
there any solution for the fortran side.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104483
--- Comment #3 from Richard Biener ---
(In reply to Prof.Dr. Selçuk Han AYDIN from comment #2)
> In this case, non of the precision gives correct answer when compared with
> wxMaxima, Maple, Mathematica or some other wide range precision calcula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102058
--- Comment #5 from Richard Biener ---
It was observed that 450.soplex needs more iterations to converge. As we now
vectorize a reduction that we didn't before that's definitely a thing that can
impact precision with FP. But this is expected w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
--- Comment #4 from Jonathan Wakely ---
(In reply to Marc Mutz from comment #0)
> the movl might not be atomic, even on x86, and then a different core may
> observe the writes out of order, which probably shouldn't happen.
Nothing in your code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104329
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Nothing in your code imposes an ordering on those stores. Another thread
> cannot observe it, because you are using non-atomic operations.
To be more precis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
Bug ID: 104484
Summary: -freorder-block-and-partition not splitting into
sections with __builin_expect()
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87510
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104472
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0f58ba4dd6b25b16d25494ae18d15dfa681f9b65
commit r12-7175-g0f58ba4dd6b25b16d25494ae18d15dfa681f9b65
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104415
Bug 104415 depends on bug 104373, which changed state.
Bug 104373 Summary: [12 regression] bogus -Wmaybe-uninitialized warning with
array new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
Marc Mutz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
--- Comment #1 from Andrew Pinski ---
There are heuristics used here. It might be also the data got lost when moving
to rtl from gimple.
But the assembly output does not make sense to the code you gave either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #16 from Jakub Jelinek ---
But just tracking those fpclassify/signbit properties wouldn't be enough,
because in many cases e.g. whether something can be infinite or not will depend
on more precise value ranges.
If we track just a bitm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #17 from rguenther at suse dot de ---
On Thu, 10 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
>
> --- Comment #16 from Jakub Jelinek ---
> But just tracking those fpclassify/signbit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
--- Comment #2 from Avi Kivity ---
(In reply to Andrew Pinski from comment #1)
> But the assembly output does not make sense to the code you gave either.
Apart from the missing .section directives, I didn't notice anything odd. Maybe
movl/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
Aaron Ballman changed:
What|Removed |Added
CC||aaron at aaronballman dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104481
--- Comment #8 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #0)
> rab0b5fbfe90168d2e470aefb19e0cf31526290bc caused:
>
> UNRESOLVED: gcc.target/i386/pr35513-8.c scan-assembler .long[ \\t]+0xb0008000
> UNRESOLVED: gcc.target/i386/pr3551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104485
Bug ID: 104485
Summary: x378 fmod inline code is slow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104485
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #8 from Jakub Jelinek ---
Which binfo has non-0 offset though?
When processing that C5 type with sz of 9, the FIELD_DECLs have C2 type and
debug_tree (field)
unit-size
...
private ignored decl_6 BLK pr102586.C:5:8 siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104485
Uroš Bizjak changed:
What|Removed |Added
Depends on||103008
--- Comment #2 from Uroš Bizjak -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:8383d41d704571d7ca234c7d2f551b7b69255194
commit r12-7180-g8383d41d704571d7ca234c7d2f551b7b69255194
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #18 from Vincent Lefèvre ---
I'm wondering whether it is possible to check on actual code what is needed.
For instance, assume that you have a program that produces always the same
results, e.g. by running it over a fixed dataset. GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #9 from Jakub Jelinek ---
Created attachment 52404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52404&action=edit
gcc12-pr102586.patch
With this WIP patch which just ignores fields that partially overlap there is
no ICE and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104485
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104458
--- Comment #6 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:69febe852753448582ae4a73793816dfb9d91c3b
commit r12-7181-g69febe852753448582ae4a73793816dfb9d91c3b
Author: H.J. Lu
Date: Thu Feb 10 06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104486
Bug ID: 104486
Summary: if constexpr versus -Wtype-limits
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104486
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104487
Bug ID: 104487
Summary: The substitution in the dependent name in a trailing
return type should cause recursive instantiation
Product: gcc
Version: 11.1.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104486
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104488
Bug ID: 104488
Summary: Wrong access specification in method pointer
assignment
Product: gcc
Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #6 from rdapp at linux dot ibm.com ---
Created attachment 52406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52406&action=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #7 from rdapp at linux dot ibm.com ---
Sorry for not getting back to this earlier, talked to Segher off-list about
this quickly.
>> The check
>>
>> if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode))
>
> With compare_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104489
Bug ID: 104489
Summary: nvptx, sm_53: internal compiler error: in
gen_rtx_SUBREG, at emit-rtl.cc:1022
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #30 from Vladimir Makarov ---
(In reply to Richard Biener from comment #29)
> (In reply to Vladimir Makarov from comment #28)
> > Could somebody benchmark the following patch on zen2 470.lbm.
>
> Code generation changes quite a bit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104489
--- Comment #1 from Tom de Vries ---
Created attachment 52407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52407&action=edit
reproducer
$ xgcc -B/home/vries/nvptx/trunk/build-gcc/./gcc/ -O2 -S mulhc3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104400
--- Comment #3 from Vladimir Makarov ---
(In reply to Jeffrey A. Law from comment #2)
> NP on the timing. My biggest concern (as always) is whether or not this is
> a generic issue or a bug in the v850 target files. The former is obviously
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #10 from Jakub Jelinek ---
So, on
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C3 : virtual C2, C1 { virtual int foo () { return 1; } };
struct C6 { char c; };
struct C7 : virtual C6, virtual C3, C1 { virtual int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #11 from Jakub Jelinek ---
Trying clang++ it agrees with g++ that both c8 and c7 are 32-bytes, contain 2
vtable pointers at offsets 0 and 16 into the objects and that c8.c is at offset
9 and c7.c is at offset 8. The big question is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104447
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #12 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #11)
> Trying clang++ it agrees with g++ that both c8 and c7 are 32-bytes, contain
> 2 vtable pointers at offsets 0 and 16 into the objects and that c8.c is at
> offs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Bug ID: 104490
Summary: Cannot inherit consteval constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104490
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #2 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:53fcc46339239c4958e2a15bb9e59274133bbcf7
commit r12-7182-g53fcc46339239c4958e2a15bb9e59274133bbcf7
Author: Uros Bizjak
Date: Thu F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:3c1242592458b478d2c88aa8305918662ea16c1c
commit r11-9551-g3c1242592458b478d2c88aa8305918662ea16c1c
Author: Uros Bizjak
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:7fbd8c0d3362bcb724db18a0bb168ade4e30f53e
commit r10-10446-g7fbd8c0d3362bcb724db18a0bb168ade4e30f53e
Author: Uros Bizjak
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104458
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:3c9a9ce0c1d5fe3d0ac93ff32d7a57e12a5fefb6
commit r11-9552-g3c9a9ce0c1d5fe3d0ac93ff32d7a57e12a5fefb6
Author: H.J. Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104458
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:0cbdb6f7662e404a72f13a1e47609ca7d80ec4fb
commit r10-10447-g0cbdb6f7662e404a72f13a1e47609ca7d80ec4fb
Author: H.J. Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:7ab70ed3aa88b7300b8027bc86268ce6bb808fef
commit r9-9946-g7ab70ed3aa88b7300b8027bc86268ce6bb808fef
Author: Uros Bizjak
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104469
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #4 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:b32305b41dcafc5fb6974c0da3ce2f62251afdbf
commit r12-7183-gb32305b41dcafc5fb6974c0da3ce2f62251afdbf
Author: Qing Zhao
Date: Thu Feb 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #5 from qinzhao at gcc dot gnu.org ---
fixed in gcc12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #8 from Segher Boessenkool ---
So I am wondering if this is something we want to do at all. It seems not
suitable for stage 4 at all.
The problem is that a "comparison" of a CC against 0 is not a comparison
at all, but the result o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104488
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 176 matches
Mail list logo
