https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108294
Bug ID: 108294
Summary: soname bump for modula2 runtime libraries
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
Bug ID: 108295
Summary: Free label positions shouldn't be available outside
-std=c2x
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
Bug ID: 108296
Summary: __builtin_memcpy generating wrong code in some cases
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #1 from Daniel Lundin ---
Created attachment 54193
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54193&action=edit
Correctly working true/false vs incorrectly free position of label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #14 from David Binderman ---
(In reply to Florian Weimer from comment #8)
> I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
> fixed this?
It looks to me like it does.
> I also brought up the initializat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #2 from Andreas Schwab ---
Free positioning of labels inside compound statements doesn't affect correctly
written programs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
Andrew Pinski changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #3 from Daniel Lundin ---
(In reply to Andreas Schwab from comment #2)
> Free positioning of labels inside compound statements doesn't affect
> correctly written programs.
No but until C23, the compiler should report an error for in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Bug ID: 108297
Summary: libtool link b2test fails: Unrecognized argument:
--build-id
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
--- Comment #2 from Nadav Har'El ---
Thanks. Interesting. So __builtin_memcpy() is simply not supposed to work
correctly for overlapping areas? I now realize that according to memcpy(3)
documentation, memcpy() is also not guaranteed to work corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
Bug ID: 108298
Summary: Wrong optimization of volatile access from gcc 11 and
beyond
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #5 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #4)
> Try -pedantic-errors.
Yes I already did and then the error appears. But that would imply that this is
a non-standard GNU extension and not an upcoming standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
Andrew Pinski changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #21 from Nadav Har'El ---
This old problem has become a real problem in gcc 12 with a real effect on
incorrect code generation, where code that copies an object was incorrectly
"optimized" to use __builtin_memcpy() instead of __builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #7 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Daniel Lundin from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > Try -pedantic-errors.
> >
> > Yes I already did and then the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #8 from Andrew Pinski ---
"When a base standard is specified, the compiler accepts all programs following
that standard plus those using GNU extensions that do not contradict it."
Wrong again.
https://gcc.gnu.org/onlinedocs/gcc-12.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #9 from Daniel Lundin ---
(In reply to Andrew Pinski from comment #8)
> "When a base standard is specified, the compiler accepts all programs
> following that standard plus those using GNU extensions that do not
> contradict it."
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #10 from Andrew Pinski ---
By conflicting means rejection of correct code. Like for an example the use of
the ident non reserved unix, etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #11 from Jakub Jelinek ---
(In reply to Daniel Lundin from comment #9)
> In this case the GNU extension does contradict the ISO 9899:2018 standard. A
> conforming compiler is required to issue a diagnostic (as per 5.1.1.3) upon
> spo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108295
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> By conflicting means rejection of correct code. Like for an example the use
> of the ident non reserved unix, etc.
The documentation even mentions that. You o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
--- Comment #5 from Daniel Lundin ---
The intention of DR 476 (Sebor)
https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476 was a
clarification leading to a volatile lvalue access being a side effect, as
opposed to an access of vola
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
Bug ID: 108299
Summary: toplevel thread_local variables are not initialized if
not referenced and initialized at wrong moment when
referenced
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:29c3218618ef6177dc33871b26c8fbd9b21eabe1
commit r13-5006-g29c3218618ef6177dc33871b26c8fbd9b21eabe1
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108286
Jakub Jelinek changed:
What|Removed |Added
Summary|[GCC 12/13] OpenMP Target |[12 Regression] OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
Bug ID: 108300
Summary: `abort()` macro cause bootstrap failure on
*-w64-mingw32
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
--- Comment #4 from Jakub Jelinek ---
I think all of the above snippets have UB, whether using memcpy,
__builtin_memcpy or
overlapping structure assignment. It is all user error.
If you need overlapping copies, always use memmove/__builtin_memm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
--- Comment #6 from Segher Boessenkool ---
(In reply to Daniel Lundin from comment #5)
> This ought to result in stricter optimizing behavior from gcc, not the other
> way around.
Well, GCC did implement this already. My request was that we sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
Segher Boessenkool changed:
What|Removed |Added
Resolution|DUPLICATE |---
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #3 from Daniel Lundin ---
(In reply to Segher Boessenkool from comment #2)
> This is not a dup of 33053 (see PR33053#c5 and PR33053#c6). Reopening, and
> confirmed. There should be a read from memory: that is a side effect, it has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107784
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #2 from Jakub Jelinek ---
See https://eel.is/c++draft/basic.start.dynamic#7 for details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:ebb1f6d14c2fef2e4e4aab30525279524c8f9145
commit r12-9030-gebb1f6d14c2fef2e4e4aab30525279524c8f9145
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265
--- Comment #4 from Jonathan Wakely ---
and for 12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #2 from Jonathan Wakely ---
This is a pre-existing problem that std::to_chars for floating-point types
doesn't work on these targets. Until I started to use std::format in
std/c++20/tzdb.cc the library wasn't using that, so the missi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #2 from LIU Hao ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to LIU Hao from comment #0)
> > 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> The C++ standard says this is undefined.
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
--- Comment #2 from Jakub Jelinek ---
Another thing is that at least for all SFmode constant one could use mov
instead of lddw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108301
Bug ID: 108301
Summary: GCC Static Analyzer evaluates "__analyzer_eval((!(((0
!= b[0]) == p_9) && p_9)))" to be TRUE in the true
branch of "if 0 != b[0]) == p_9) && p_9))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #3 from Jonathan Wakely ---
I have a workaround for this, but bootstrap still fails for me at:
/tmp/ccC7KXoL.s: Assembler messages:
/tmp/ccC7KXoL.s:82719: Error: value of 0001254e too large for field of 2 bytes
at 0002
make[6]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #21 from Piotr Kubaj ---
I'm not sure whether it will help, but the issue only affects building 32-bit
multilib libraries on powerpc64. That is, building a full 32-bit gcc for
powerpc works just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #2 from Jakub Jelinek ---
The assembly difference is
- movl$1, x+20(%rip)
+ movl$-6, x+20(%rip)
Now, that is the correct value to be stored into x[5] by the
__builtin_sub_overflow (0, 6, &x[5]);
statement, but eac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #1 from Jonathan Wakely ---
I've tried to reproduce this, but it depends on the addresses of the
_Safe_iterator objects that get created, because they'll use different mutexes
unless their addresses collide in the hash function.
Wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #3 from Andrea Griffini ---
Thread storage duration is different from static storage duration.
The text I found on the topic is different from the one you are linking,
but even in this version (that is indeed more permissive) it's e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #3 from Jonathan Wakely ---
This was my reproducer, although it doesn't deadlock without the hack to use a
single mutex for all objects.
#define _GLIBCXX_DEBUG 1
#include
int main()
{
std::vector v{1,2,3};
auto i = v.begin();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #4 from Jakub Jelinek ---
flag2 doesn't have dynamic initialization, if you add dynamic initialization to
it, you'll see that flag is constructed before flag2 and that happens before it
is referenced in the current thread (after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #5 from Andrea Griffini ---
So you are saying that the standard forgot to add "that requires dynamic
initialization" and that this is the intention?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #4 from Segher Boessenkool ---
But please use PR33053 for that, or open a new PR? Let's keep this one
for just this actual bug :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108302
Bug ID: 108302
Summary: void fn (uint8_t auto... args); leads to internal
compiler error: Segmentation fault
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #7 from Jonathan Wakely ---
Comment 0 seems wrong to me, there is no requirement that flag is initialized
if not odr-used, and if it is initialized, it doesn't have to happen before the
printf statement.
I agree that the standard sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #8 from Jonathan Wakely ---
FWIW the current wording in the standard was introduced by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0250r3.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #9 from Andrea Griffini ---
I agree that comment 0 is wrong and was based on a text that I thought was
taken from the standard but apparently was not (cppreference.com). Sorry for
the noise.
I think that if the dynamic initializatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108130
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:80ff207da6d8784e227eb93f75c4ac5a300c8420
commit r13-5034-g80ff207da6d8784e227eb93f75c4ac5a300c8420
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e2eab3c4edb6aa9a93f982c4554cd756000934ca
commit r13-5033-ge2eab3c4edb6aa9a93f982c4554cd756000934ca
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #8 from Surya Kumari Jangala ---
Using -O3 with gcc13, I got (with the test in comment 2):
For P8:
cmpwi 0,3,2
bgt 0,.L3
subfic 4,4,9
srdi 3,4,63
xori 3,3,0x1
rldicl 3,3,0,63
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
--- Comment #3 from Jose E. Marchesi ---
(In reply to Jakub Jelinek from comment #2)
> Another thing is that at least for all SFmode constant one could use mov
> instead of lddw.
For this I guess we could expand the "I" constraint to cover cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #16 from Martin Jambor ---
I have posted the sorting patch to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609459.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #4 from Simon Marchi ---
Thanks for looking into this so quickly. I'll try to test the patch against my
use case, but I might need some guidance. I know how to build gcc and install
it in some non-default prefix. But then, do I ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:4413365616e8c6024d1ff4e23309e5012ee33b9f
commit r13-5035-g4413365616e8c6024d1ff4e23309e5012ee33b9f
Author: Iain Sandoe
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #5 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54184 [details]
> Potential fix for target multilib_dir handling -m and -f.
>
> Work in progress.
1. (I think) the string you need is "multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #5 from Segher Boessenkool ---
This is not x86-specific. Like on powerpc64 we get
addi 3,3,3 # 11 [c=4 l=4] *addsi3/1
extsw 3,3# 17 [c=4 l=4] extendsidi2/1
blr # 25 [c=4 l=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #5 from Jakub Jelinek ---
Though, it seems the REG_EQUAL note is also wrong on the cmov10.c testcase
which went with the commit (again, exact opposite).
Seems we have multiple cases where this REG_EQUAL note is newly added.
One is x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #5 from Jonathan Wakely ---
The patch doesn't change libstdc++.so, it only changes the headers.
You don't even need to rebuild GCC. You could just put a patched copy of
safe_iterator.h in /tmp/x/debug and then compile with -I/tmp/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303
Bug ID: 108303
Summary: lookup failes with requires clause on non-template
friend function of a class template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #6 from Jakub Jelinek ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj 2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc 2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@ ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #7 from Jakub Jelinek ---
Or for now don't add any REG_EQUAL note if op0 has scalar floating point
mode...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #6 from Simon Marchi ---
Because some code trying to acquire the lock (see frame #7 in my backtrace) is
in debug.cc, I thought it would maybe need to be changed too? But I don't
really understand any of this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #7 from Jonathan Wakely ---
__gnu_debug::_Safe_iterator_base::_M_detach in debug.cc isn't affected by the
patch though.
The fix is to the post-inc and post-dec members, so only the code that calls
those needs to be recompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #8 from Simon Marchi ---
I tested with just patching my /usr/include, and it looks like it works fine,
I'm able to run a program under my GDB. Removing the fix, I get back the hang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #8 from Roger Sayle ---
Created attachment 54195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195&action=edit
Roger's proposed patch
Here's my proposed patch (or something close to it, it's still bootstrapping
and regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108304
Bug ID: 108304
Summary: FAIL: 20_util/from_chars/4.cc execution test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #9 from Roger Sayle ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
/* Add a REG_EQUAL note to allow condition to be shared. */
rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
/* TMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #10 from Jakub Jelinek ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
>
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:12b0d35ec52375da5652d2b8da74083ab700b9d7
commit r13-5037-g12b0d35ec52375da5652d2b8da74083ab700b9d7
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing). The goal
1 - 100 of 141 matches
Mail list logo
