https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
--- Comment #2 from Nathan Sidwell ---
That change looks suspicious in its own right -- it ends up mutating the
initializer during the adding of overload candidates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
c,c++,fortran --enable-threads=posix --disable-nls
--enable-__cxa_atexit --enable-clocale=gnu --enable-checking=release
--disable-libstdcxx-pch --disable-libsanitizer --disable-libcilkrts
--without-isl --disable-werror
Thread model: posix
gcc version 9.0.0 20190116 (experimental) [trunk revision 267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Richard Biener changed:
What|Removed |Added
Target||ia64
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
--- Comment #8 from Jakub Jelinek ---
Or if 7.3 works and 8.x doesn't and the two are ABI compatible (dunno about
mingw), then you could after you find problematic *.ii file try to bisect which
compiler revision changed the behavior and from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876
Bug ID: 88876
Summary: [9 regression] ICE in propagate_pure_const
ipa-pure-const.c:1502
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Bug ID: 88877
Summary: rs6000 emits signed extension for unsigned int
type(__floatunsidf).
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88847
--- Comment #2 from Tamar Christina ---
Using stack protector created an invalid addressing mode.
It changes SP-64 into SP-80, presumably due to it storing the canary value.
However 80 is not a multple of SVE_BYTE_MODE (32) so the instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #7 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #6)
> Could be a result of my recent commit, r267953. I'll take a look tonight.
That would be my guess, too,
I think it has to do with the array
descriptor together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88861
--- Comment #6 from David Malcolm ---
(In reply to Segher Boessenkool from comment #5)
> Cool, thanks! Is the plan to simply not allow something that can throw to be
> recognised as noop move?
Candidate patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #1 from Kamlesh Kumar ---
Following patch fixes the problem but would like to know the experts thought on
the below patch .
static machine_mode
-rs6000_promote_function_mode (const_tree type ATTRIBUTE_UNUSED,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88876
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.0 |---
Summary|[7/8/9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
Bug ID: 88878
Summary: .debug_pubnames/types empty with -flto
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70682
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.0 |10.0
--- Comment #6 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Bug ID: 88879
Summary: [9 Regression] ICE in sel_target_adjust_priority, at
sel-sched.c:3332
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Bug ID: 88875
Summary: [8 regression] initializer_list and explicit ctor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88861
--- Comment #5 from Segher Boessenkool ---
Cool, thanks! Is the plan to simply not allow something that can throw to be
recognised as noop move?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736
--- Comment #12 from Richard Biener ---
OK, so C++ has
else if ((DECL_NAME (decl) == NULL_TREE)
&& TREE_CODE (decl) == NAMESPACE_DECL)
dump_decl (cxx_pp, decl, TFF_PLAIN_IDENTIFIER | TFF_UNQUALIFIED_NAME);
and thus "copes"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #2 from Richard Biener ---
A little detail is that host GCC is GCC 4.1.2 which happened to miscompile GCC
itself for quite a while (but now somehow we're back).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88870
--- Comment #3 from Richard Biener ---
fast_dce gathers postorder and friends computing all_blocks before it
eventually does
if (global_changed)
{
/* Turn off the RUN_DCE flag to prevent recursive calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #9 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88869
--- Comment #3 from Jakub Jelinek ---
Note the auto return type on foo isn't important, it ICEs even with void foo ()
{ C ([] {}); }
The ICE is in
26858 tparms = DECL_TEMPLATE_PARMS (fn_tmpl);
26859 /* If type is a member class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #60 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 16 14:18:47 2019
New Revision: 267970
URL: https://gcc.gnu.org/viewcvs?rev=267970=gcc=rev
Log:
PR c/51628
PR target/88682
* c-c++-common/pr51628-10.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80762
--- Comment #14 from Tamar Christina ---
Hi Jonathan,
You're right, I was going off the results of a script but it doesn't seem to
have detected the change between FAIL -> UNSUPPORTED and left the state as
FAIL.
Sorry, I've manually checked it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
version 9.0.0 20190116 (experimental) [trunk revision 267961] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #17 from Jakub Jelinek ---
Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from the
above committed change + fixing up ptrs_compare_unequal, or something
equivalent like the VRP change) I'm afraid there isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #4 from Jürgen Reuter ---
(In reply to Richard Biener from comment #3)
> Seems to work on the branches but I can't reproduce on trunk either.
That is strange. Did you try to compile several
times? Sometimes it comes, sometimes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #8 from Dominique d'Humieres ---
> My suspicion goes toward the fix for PR81849
Debugger shows
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
frame #0: 0x0001000b2e1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #10 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #25 from Richard Biener ---
When considering the patch from comment#18 additional data is that only
95802 out of 636160 disambiguations that ultimately require base_alias_check
involve non-CONST_INT_P "other" operand. That is out of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88682
--- Comment #8 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 16 14:18:47 2019
New Revision: 267970
URL: https://gcc.gnu.org/viewcvs?rev=267970=gcc=rev
Log:
PR c/51628
PR target/88682
* c-c++-common/pr51628-10.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #1 from Andrew Pinski ---
That inline asm looks big and suspicious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #8 from Marek Polacek ---
That is most likely a bug in the package. GCC 8 wasn't very good at detecting
narrow conversions, but in GCC 9 things have improved, so probably we just
detect invalid code now. The problem in this PR is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88864
--- Comment #1 from Jonathan Wakely ---
I'm pretty sure this is a dup of an existing bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88864
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396
Jonathan Wakely changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #3 from Jonathan Wakely ---
The "nonexistent-path/.." part is reported as
https://sourceforge.net/p/mingw-w64/bugs/782/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #8 from Segher Boessenkool ---
There is no bug, so we don't have to do anything.
To make slightly better code we could make the soft float routines be
prototyped?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
>
> As an experiment I hacked the AArch64 assembly of the function generated
> with -funroll-loops to replace the peeled prologue version with a simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2016-01-24 00:00:00 |2019-1-16
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #2 from Andrew Pinski ---
The inline asm modifies the 0th and 1st operands. I think the inline asm is
broken .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
Bug ID: 3
Summary: [AArch64] gcc/config/aarch64/aarch64.opt:
aarch64_branch_protection_string type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
--- Comment #18 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #17)
> Without the #c11 patch (+ removal of the !INTEGRAL_TYPE_P special case from
> the above committed change + fixing up ptrs_compare_unequal, or something
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #11 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:18:05 2019
New Revision: 267971
URL: https://gcc.gnu.org/viewcvs?rev=267971=gcc=rev
Log:
__builtin__overflow issues on AArch64 (redux)
Further investigation showed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214
--- Comment #12 from Martin Jambor ---
Author: jamborm
Date: Wed Jan 16 15:41:07 2019
New Revision: 267975
URL: https://gcc.gnu.org/viewcvs?rev=267975=gcc=rev
Log:
[PR 88214] Check that an argument is a pointer
2019-01-16 Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #4 from Andrew Pinski ---
Replace:
:
:
"r" (i),
"r" (n),
With:
:
"+r" (i),
"+r" (n),
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78244
--- Comment #9 from Marek Polacek ---
Author: mpolacek
Date: Wed Jan 16 15:58:34 2019
New Revision: 267976
URL: https://gcc.gnu.org/viewcvs?rev=267976=gcc=rev
Log:
PR c++/78244 - narrowing conversion in template not detected.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
--- Comment #9 from Steve Kargl ---
On Wed, Jan 16, 2019 at 07:13:37AM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
>
> --- Comment #8 from Jürgen Reuter ---
> I think this fix or something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
--- Comment #3 from Jakub Jelinek ---
Actually, with -Wsystem-headers we do warn about that:
include/arm_neon.h:33073:9: warning: ‘#pragma GCC option’ is not a string
[-Wpragmas]
33073 | #pragma GCC target(("arch=armv8.2-a+sm4"))
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046
--- Comment #7 from Tamar Christina ---
Author: tnfchris
Date: Wed Jan 16 17:50:38 2019
New Revision: 267980
URL: https://gcc.gnu.org/viewcvs?rev=267980=gcc=rev
Log:
Fix PR88046 on AArch64 and Arm bare metal targets.
gcc/testsuite/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
--- Comment #4 from Tamar Christina ---
Hi Jakub,
Thanks for the patch, I've started a testrun but the fix looks sensible to me.
I'll post the result as soon as it's finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Bug ID: 2
Summary: gcc generates wrong debug information at -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86736
--- Comment #13 from Iain Sandoe ---
(In reply to Richard Biener from comment #12)
> OK, so C++ has
>
> else if ((DECL_NAME (decl) == NULL_TREE)
>&& TREE_CODE (decl) == NAMESPACE_DECL)
> dump_decl (cxx_pp, decl,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #6 from Segher Boessenkool ---
Sure, with 32-bit ABIs the registers are just 32 bits, for all intents and
purposes.
But we have -m64 here. (see also the "lwa" insn).
I think that because __floatunsidf has no prototype all its args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
--- Comment #10 from Jürgen Reuter ---
Actually, it was Thomas Koenig in r267953, so not your commits, but very
close.^^ The report is PR88871.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #4 from MCCCS ---
Iain could you please test if this patch works for you
too? If so, I'll send it as a patch tomorrow
(For me, it even fixes g++.dg/other/darwin-cfstring1.C):
Index: fixincludes/fixincl.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #11 from ktkachov at gcc dot gnu.org ---
Thank you all for the input.
Just to add a bit of data.
I've instrumented 510.parest_r to count the number of loop iterations to get a
feel for how much of the unrolled loop is spent in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Bug ID: 4
Summary: std::filesystem::absolute("//") does not produce an
absolute path on mingw
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #4 from Marek Polacek ---
There can be three scenarios:
1) decltype is in a template and it has no dependent expressions -- PROBLEM
- we call finish_compound_literal from cp_parser_functional_cast
- processing_template_decl is 1, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #6 from Martin Liška ---
Upstream bug:
https://github.com/xianyi/OpenBLAS/issues/1964
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86610
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88859
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2019-1-16
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891
--- Comment #12 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Jan 16 15:22:08 2019
New Revision: 267972
URL: https://gcc.gnu.org/viewcvs?rev=267972=gcc=rev
Log:
__builtin__overflow issues on AArch64 (redux) (cont)
And the ChangeLog for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #5 from Marek Polacek ---
(My proof-of-concept patch to deal with narrowing in decltype fixed this PR as
a result.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88684
--- Comment #11 from Rafael Avila de Espindola ---
(In reply to Martin Liška from comment #10)
> > That said, I'm willing to ack it for GCC9 even then if upstream comes up
> > with something or if they don't care, eventually as a GCC only tweak.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Tomáš Trnka changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #2 from Jonathan Wakely ---
But that fix looks wrong, it means "file/" will resolve to "file" and that's
wrong a for a non-directory, because "file/" should fail.
Testcase demonstrating the mingw bugs:
#include
#include
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #9 from Marek Polacek ---
(In reply to Marek Polacek from comment #4)
> So one idea would to be to walk_tree on the expression at the end of
> finish_decltype_type, looking for compound literals and call check_narrowing.
Scratch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88865
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
Bug ID: 0
Summary: Wrong code since r264897
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Bug ID: 1
Summary: std::filesystem::status gives bad results on mingw32
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #4 from Bill Schmidt ---
"Values shorter than 32 bits are sign-extended or zero-extended, depending on
whether they are signed or unsigned." Source:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214
--- Comment #11 from Martin Jambor ---
Author: jamborm
Date: Wed Jan 16 15:37:33 2019
New Revision: 267974
URL: https://gcc.gnu.org/viewcvs?rev=267974=gcc=rev
Log:
[PR 88214] Check that an argument is a pointer
2019-01-16 Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #3 from Martin Liška ---
(In reply to Andrew Pinski from comment #2)
> The inline asm modifies the 0th and 1st operands. I think the inline asm is
> broken .
You are right, they are modified. Can you please help me how to fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
--- Comment #6 from Marek Polacek ---
And of course r265789 changed int{(p(), 0U)} from being dependent to being
non-dependent, so scenario 2) to scenario 1).
1 - 100 of 176 matches
Mail list logo
