||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
The compiler cannot perform this hoisting, because the computation 'n*(i) +
(j)' happens in 'unsigned int' type, where wrapping overflow matters when
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Controlling expression in _Generic undergoes lvalue conversion, so it will have
const/volatile qualifiers stripped. Therefore, a qualified
-*-*
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Keywords||wrong-code
Last reconfirmed||2019-04-20
CC||amonakov at gcc dot gnu.org
Ever
||2019-04-16
CC||amonakov at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #6 from Alexander Monakov ---
Reopening and confirming, GCC's code looks less
||2019-04-12
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexander Monakov ---
Please provide an example, as a simple smoke-test is compiled correctly:
long f(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #4 from Alexander Monakov ---
Well, often sel-sched just does not discriminate hardregs and pseudos when
checking if renaming/substitution may be applied. Sure, as a matter of
efficiency we should probably disallow substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #2 from Alexander Monakov ---
We have a pseudo:SI<-hardreg:SI assignment followed by
pseudo:DF<-float(pseudo:SI) conversion, and we substitute the latter through
the former, creating a pseudo:DF<-float(hardreg:SI) insn that fails in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85876
--- Comment #3 from Alexander Monakov ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 15:45:57 2019
New Revision: 270096
URL: https://gcc.gnu.org/viewcvs?rev=270096=gcc=rev
Log:
sel-sched: skip outer loop in get_all_loop_exits (PR 84206)
2019-04-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85876
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 15:39:22 2019
New Revision: 270095
URL: https://gcc.gnu.org/viewcvs?rev=270095=gcc=rev
Log:
sel-sched: fixup reset of first_insn (PR 85876)
2019-04-02 Andrey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
Bug 86928 depends on bug 89916, which changed state.
Bug 89916 Summary: New test case gcc.dg/pr86928.c fails on 64 bit targets
(r270061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 11:04:22 2019
New Revision: 270087
URL: https://gcc.gnu.org/viewcvs?rev=270087=gcc=rev
Log:
testsuite: do not try to add -m32 (PR 89916)
PR testsuite/89916
||2019-04-02
Blocks||86928
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks. I assume the test should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
Alexander Monakov changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
--- Comment #14 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 18:05:08 2019
New Revision: 270065
URL: https://gcc.gnu.org/viewcvs?rev=270065=gcc=rev
Log:
sel-sched: correct reset of reset_sched_cycles_p (PR 85412)
2019-04-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 86928, which changed state.
Bug 86928 Summary: ICE in compute_live, at sel-sched.c:3097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 16:32:24 2019
New Revision: 270061
URL: https://gcc.gnu.org/viewcvs?rev=270061=gcc=rev
Log:
sel-sched: update liveness in redirect_edge_and_branch hooks (PR 86928)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
--- Comment #6 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 15:20:13 2019
New Revision: 270059
URL: https://gcc.gnu.org/viewcvs?rev=270059=gcc=rev
Log:
sel-sched: remove assert in merge_fences (PR 87273)
2019-04-01 Andrey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
--- Comment #17 from Alexander Monakov ---
> Can the bogus situation be reproduced with C _Alignas?
C11 does not allow _Alignas on typedefs, so don't see how; likewise for alignas
in C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #6 from Alexander Monakov ---
... and even considering that the standard never actually says that "compatible
type" relation is transitive, and so two enums technically need not be
compatible with each other, the following should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #5 from Alexander Monakov ---
C11 6.7.2.2 p4 says,
Each enumerated type shall be compatible with char, a signed integer type, or
an unsigned integer type [...]
and 6.5 p7 says,
An object shall have its stored value accessed
-07-29 00:00:00 |2019-3-14
CC||amonakov at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Alexander Monakov ---
Optimized to 'return 1' already in fre1.
At the same time, accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Fri Mar 1 16:18:04 2019
New Revision: 269319
URL: https://gcc.gnu.org/viewcvs?rev=269319=gcc=rev
Log:
haifa-sched: handle fallthru edge to EXIT block (PR 85899)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #4 from Alexander Monakov ---
It appears that fallthru edges to the exit block are unusual in that they don't
obey the invariant e->dest == e->src->next_bb (i.e. next_bb may be anything).
If so, the assert in haifa-sched needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Mon Feb 25 15:14:39 2019
New Revision: 269189
URL: https://gcc.gnu.org/viewcvs?rev=269189=gcc=rev
Log:
df-scan: fix use of mw_order in df_mw_compare (PR 86096)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89436
--- Comment #2 from Alexander Monakov ---
This was previously reported as PR 86096. Let me copy-paste my response from
there:
df_mw_compare has:
if (mw1->mw_reg != mw2->mw_reg)
return mw1->mw_order - mw2->mw_order;
Note mw_reg in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from Alexander Monakov ---
As far as I can tell this report was not correctly triaged 10 years ago, as
that's exactly what -mtune= is for: optimize for a given CPU without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
Alexander Monakov changed:
What|Removed |Added
CC||vermaelen.wouter at gmail dot
com
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #3 from Alexander Monakov ---
This was implemented for gcc-9 via PR 82853; it seems this bug was overlooked
in the renewed discussion.
*** This bug has been marked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #25 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #22)
> A function call must be assumed to clobber any call used registers of course.
> But calls already do have vops (well, const/pure don't, and I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #21 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #18)
> We could cache a bool in struct function whether the function has any local
> hard register vars and just propagate that info during inlining etc. and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #17 from Alexander Monakov ---
Well, the asm with the xor was just to make the testcase more-obviously-broken,
it's still broken when %eax is clobbered in a more subtle way, like via a
libcall for integer division like in earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 88698, which changed state.
Bug 88698 Summary: Relax generic vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #11 from Alexander Monakov ---
Author: amonakov
Date: Mon Feb 4 15:00:41 2019
New Revision: 268522
URL: https://gcc.gnu.org/viewcvs?rev=268522=gcc=rev
Log:
doc: showcase a "union of vectors" pattern (PR 88698)
PR c/88698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106
--- Comment #4 from Alexander Monakov ---
My concern is that the cast does not "create a compound literal": what it
creates is an object, more specifically, an unnamed temporary object in
automatic storage with unspecified lifetime [1]. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106
--- Comment #2 from Alexander Monakov ---
I don't think it's appropriate to say "creates a compound literal". My
preference would be:
Unlike a compound literal, a cast to a union yields an rvalue like standard
casts do.
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
The patch for PR 71560 changed the wording in "Cast to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #3 from Alexander Monakov ---
Note, without the attribute gcc passes the union on an SSE register, so it
doesn't look like TImode on the union matters (otherwise it would be passed via
rdx:rax register pair):
typedef unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #1 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #0)
> Adding a dummy __int128 field makes GCC accept the code (but such workaround
> won't work for wider vectors, or on 32-bit).
But this causes the union to
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC (and Clang) rejects an attempt to create a transparent union corresponding
to an SSE register:
typedef unsigned long u64x2 __attribute__ ((vector_size (16)));
typedef
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=88793
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #3)
> I think it's fair to raise the question if gcc should not use scasb/cmpsb by
> default (I thought there was a bug for that but apparently there isn't?).
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Performance difference between libc strlen and x86 rep-scasb has grown too
large and seems unlikely to improve anytime soon.
On most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #8 from Alexander Monakov ---
Yeah, on GCC users' side I think there's a demand for both: treating UB as
unreachable (e.g. on tiny systems with heavy program size constraints) and
transforming UB to a trap briefly annotated with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
--- Comment #3 from Alexander Monakov ---
(In reply to Florian Weimer from comment #2)
> The startup overhead isn't the problem. The asymptotic performance is
> really bad, too. (I hope I didn't botch my test, though. It's vaguely
> based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #10 from Alexander Monakov ---
As discussed with Andrew offline, the real problem is creating a path where
stack pointer is decremented twice - that is really not supposed to happen (so
the issue could appear even in absence of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #4 from Alexander Monakov ---
It seems to avoid this sort of gotchas cleanup_cfg should
gcc_checking_assert (!dom_info_available_p (CDI_DOMINATORS));
gcc_checking_assert (!dom_info_available_p (CDI_POST_DOMINATORS));
but maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #9 from Alexander Monakov ---
Thanks. I still don't see what's wrong. Are you testing only by single-stepping
in gdb, or does your program overall behave differently with/without
if-conversion?
In other words, do you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425
--- Comment #4 from Alexander Monakov ---
Thanks! Should this be closed as fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #6 from Alexander Monakov ---
And just to be sure, can you confirm that -fno-if-conversion changes program
behavior (the testcase is not executable so I cannot check), and the issue is
not about debug info quality (i.e. that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #5 from Alexander Monakov ---
The code shown in the opening comment looks fine to me, so please isolate the
issue further using debug counters.
Add -fdbg-cnt=if_conversion:99,if_after_combine:99 to -O1. This should lead to
broken
||2018-12-13
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Without -O, optimization passes are not enabled, even if individual -f options
are passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345
--- Comment #6 from Alexander Monakov ---
I think gcc_qsort doesn't really change things here, validation failure implies
a logic issue in the comparator, so some step is not always working as the
author intended.
And even with gcc_qsort it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #3)
> But unfortunately today we don't manage to use the cmp-sbb trick for
> unsigned comparison against an immediate, i.e. for
>
> unsigned long baz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425
Bug ID: 88425
Summary: suboptimal code for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #3 from Alexander Monakov ---
However, this may be worthwhile when one of operands is an immediate, as in
that case there's no register pressure increase, and the xor just mutates the
immediate.
Essentially, we'd change e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #6 from Alexander Monakov ---
If this is fixed then the testcase should be added to the testsuite to make
sure we catch it if we regress again (this worked before e.g. on gcc-4.1).
Peter, can you please clarify, is this actually
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
With -std=c++17 GCC segfaults on
template
int f()
{
return 0;
}
template int f();
Clang accepts with -fsyntax-only, segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #15 from Alexander Monakov ---
Typo: PR 42491 should have said PR 43491.
Hopefully more obviously-broken testcase with an inline function:
static inline void
ff(int *o)
{
register int a asm("eax");
a = 1;
asm("add %1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #14 from Alexander Monakov ---
With -fno-tree-fre it's still broken.
How long will GCC play this sort of whack-a-mole with ad-hoc restrictions to
gimple optimizations (PR 29877, PR 42491, PR 61572)?
And this:
> for fixed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88302
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88279
--- Comment #4 from Alexander Monakov ---
To clarify, the decl/type mixup is causing the compiler to use local-dynamic
TLS references where general-dynamic are intended (and were used prior to the
patch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88279
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
|WAITING |NEW
CC||amonakov at gcc dot gnu.org
Known to work||4.3.2
Summary|Invalid tree PRE|[7/8/9 Regression] Invalid
|optimization around |tree PRE
||amonakov at gcc dot gnu.org
Component|c |tree-optimization
Summary|Wrong code for intrinsic|[8/9 Regression] Wrong code
|memmove |for intrinsic memmove
--- Comment #2 from Alexander
||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
It's tricky to use macro-expanded expressions in scope of default(none), you
never know what the expansion is going to reference. This is not limited to the
assert macro (or to its use of __PRETTY_FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855
Alexander Monakov changed:
What|Removed |Added
CC||giuliano.belinassi at usp dot
br
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
See PR 65855.
*** This bug has been marked as a duplicate of bug 65855 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
--- Comment #28 from Alexander Monakov ---
It seems like object file is not correctly assembled, note wrong offset to the
last instruction (movdqu):
.s:
vpgatherqd (%rax,%ymm3,4), %xmm4{%k4}
vpgatherqd (%rax,%ymm1,4),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
--- Comment #24 from Alexander Monakov ---
Janus, can you attach your .s and .o files please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #11 from Alexander Monakov ---
Just for information: the extra flag is needed due to --enable-default-ssp on
Arseny's configure command line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #17 from Alexander Monakov ---
Test shown in comment #2 is still not optimized at -O2, so as comment #12 said,
> Load part remains.
Not sure if that needs to be split off into a separate bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #9 from Alexander Monakov ---
Martin, Jakub: if I add -fstack-protector-strong, the problem is reproducible
for me - can you try that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #9 from Alexander Monakov ---
Actually, no long division needed, broken with a plain move as well:
__attribute__((weak))
int f(void)
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #8 from Alexander Monakov ---
Executable testcase suitable for bisecting, aborts with -O2 -m32
__attribute__((weak))
int f(long long x[])
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
501 - 600 of 1128 matches
Mail list logo
