https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #5 from Alexander Monakov ---
On trunk, manually fixing up inlining is not enough: trunk additionally needs
-fno-tracer, otherwise crucial if-conversion of 'if (k < 0) k += m1;' is
prevented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #6 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #4)
> To the value in the other BB/function. This works if the jump
> targets are semantically compatible. For function cloning it's
> probably hard to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #3 from Alexander Monakov ---
... unless labels are intended to act similar to non-static function-scope
variables, with computed address usable only until the containing function
returns? Except when used in static initializers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #2 from Alexander Monakov ---
(In reply to Richard Biener from comment #1)
> The question is whether the transform at hand is valid if the label is
> duplicated
> but all referers still refer to the original one (so if the label is
: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Today, GCC considers all BBs clonable on GIMPLE, as indicated by
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #4 from Alexander Monakov ---
It might have been nicer to adjust asms themselves, adding inputs/outputs for
each global reg, if we must pretend the asms implicitly read/write them. That
would allow any subsystem (df, sched-deps,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #3 from Alexander Monakov ---
Since r235809, in df-scan.c:df_insn_refs_collect, there's
3233 if (asm_noperands (PATTERN (insn_info->insn)) >= 0)
3234 for (unsigned i = 0; i < FIRST_PSEUDO_REGISTER; i++)
3235 if
||2017-03-10
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks for the nice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570
Alexander Monakov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #8 from Alexander Monakov ---
Well, if my argument is correct, then GCC generates wrong code for the very
first example in comment #0. If that is deliberate as a compromise even though
otherwise GCC suppresses optimizations to honor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #2 from Alexander Monakov ---
Not sure how well this qualifies as a regression: prior to 4.9, there was no
OpenMP SIMD support, so 4.8 just diagnoses a warning for an unrecognized
omp-simd pragma.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78831
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78831
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Wed Dec 21 14:20:09 2016
New Revision: 243855
URL: https://gcc.gnu.org/viewcvs?rev=243855=gcc=rev
Log:
nvptx: do not assume that crtl->is_leaf is unset
PR target/78831
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Noticed this ICE when looking at OpenMP gimplification/lowering:
void use(int*);
void f(int n)
{
#pragma omp simd
||2016-12-16
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks. This is due to r243347. After that change, crtl->is_leaf is
initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589
--- Comment #3 from Alexander Monakov ---
Ah, sorry if I misunderstood and got carried away.
>From my investigation it looks like for the '' issue it's just a
matter of setting DECL_ABSTRACT_ORIGIN in create_omp_child_function (not sure
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Alexander Monakov ---
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67822
--- Comment #3 from Alexander Monakov ---
Author: amonakov
Date: Thu Nov 24 18:10:42 2016
New Revision: 242842
URL: https://gcc.gnu.org/viewcvs?rev=242842=gcc=rev
Log:
Allow -fopenmp in NVPTX mkoffload
PR target/67822
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following C++ testcase:
#include
long foo(char *c1, char *c2)
{
long *p1 = new(c1) long;
*p1 = 100;
long long *p2 = new(c2) long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #7 from Alexander Monakov ---
Richard, I don't believe this is a dup. According to my git-bisect, this was
fixed or made latent during gcc-6 development by your patch:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00120.html
[PATCH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #6 from Alexander Monakov ---
Thanks, seeing alignment info in dumps helps (I think you meant -vops rather
than -alias?).
This doesn't seem to reproduce on trunk. On gcc-5 branch, I see alignment
increasing in dom2 pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #4 from Alexander Monakov ---
Slightly reduced testcase that demonstrates the issue regardless of
stack-protector; -O3 -ffast-math is enough on x86-64 (plus -msse2 on i386).
Oddly, the #if0 block makes a difference.
static const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
--- Comment #3 from Alexander Monakov ---
On further investigation, lack of peeling might be intentional, the vectorizer
could be deliberately using unaligned access. Previously I missed that the body
of the vectorized loop is completely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77478
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77453
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #8 from Alexander Monakov ---
> The extension is closely modeled after openCL
Hm, that doesn't sound right: gcc had vector types long before OpenCL was even
a thing; I believe it's modeled after Altivec actually: the discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #6 from Alexander Monakov ---
Thanks. Any comment on having gimple lowering emit cleaner code in the first
place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
Alexander Monakov changed:
What|Removed |Added
Summary|SLP does not handle |Poor code generation for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #1 from Alexander Monakov ---
I should also mention that for scalar code:
void f(float *o, int *i)
{
*o++ = *i++; *o++ = *i++; *o++ = *i++; *o++ = *i++;
}
where SLP vectorization succeeds, one can see that c-style casts exist for
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: nsz at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
typedef int v4si __attribute__((vector_size(16
: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
static char c[] = {[~0ul] = 1};
the array c would
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Alexander Monakov ---
The library is not unloaded on glibc due to STB_GNU_UNIQUE binding on get::i.
You can opt-out of creating symbols with that binding using -fno-gnu
||2016-07-23
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
This is most likely a duplicate of bug 71702. I've talked with the reporter
briefly on IRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
Alexander Monakov changed:
What|Removed |Added
CC||tony at kelman dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71910
--- Comment #3 from Alexander Monakov ---
Created attachment 38922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38922=edit
preprocessed testcase
I can also reproduce this on 5.4 and trunk with a cross-compiler configured
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71910
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71844
--- Comment #2 from Alexander Monakov ---
Jakub, this code is taken verbatim from the openmp-examples document. Should we
report it at their github issue tracker? The example in their public git has
always been without the A[0:4] map on 'omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
--- Comment #3 from Alexander Monakov ---
On 6/trunk, this issue is fixed or made latent by r230667 that added
+ STRIP_NOPS (t1);
+ STRIP_NOPS (t2);
to tree-vect-data-refs.c:compare_tree (patch submission here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
Alexander Monakov changed:
What|Removed |Added
Attachment #38793|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
--- Comment #1 from Alexander Monakov ---
Created attachment 38794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38794=edit
qsortchk.c
quick'n'dirty LD_PRELOAD transitivity validator for qsort comparator
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 38793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38793=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71524
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71536
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71495
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Mon May 30 14:37:02 2016
New Revision: 236882
URL: https://gcc.gnu.org/viewcvs?rev=236882=gcc=rev
Log:
match.pd: optimize unsigned mul overflow check
gcc/
2016-05-28 Alexander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #2 from Alexander Monakov ---
> What do the dumps look like? Gcc is likely to change things to -1 / B < A,
> which you don't handle...
The dumps didn't help much, but you're right that normally the order is
opposite, thanks (I
ion
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
If A and B are both unsigned, then 'A > -1 / B' is a nice predicate for
checking w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
--- Comment #3 from Alexander Monakov ---
I like to avoid touching generic stuff for issues like this one. Please see
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01022.html for a brief outline of
an alternative solution: I think my proposal of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71064
--- Comment #1 from Alexander Monakov ---
> (It's generally tuned for speed instead of precision, and does not strive for
> full IEEE-754 conformance.)
(PTX is an abstract ISA, if it's tuned for anything it's the simplicity of
abstraction and
-invalid, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
OpenMP 4.5 says (4.0 had a similar restriction, sans 'declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #2 from Alexander Monakov ---
Bah, please disregard the last point; '\9' is diagnosed similar to "\9".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #1 from Alexander Monakov ---
Octal escapes have no more than three digits by definition, so "\0009" clearly
doesn't fall under this warning.
Upon further testing, there's no diagnostic for
const char c = '\9'; /* same as ... = 9;
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC doesn't warn for:
const char s[] = "\008";
(just the two zeros following the backslash become a part of the octal l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
int f(int (**p)(void))
{
return -p[1]();
}
gcc-6 -O2 produces:
f
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
int i=0;
#pragma omp task default(shared) if(0)
{
#pragma omp simd
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
int f(long a)
{
int *p=(int*)(a<<1);
//asm("" : "+r"(p));
return *p;
}
Starting from 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65362
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #10 from Alexander Monakov ---
If always using r0 is not an issue, I think it's possible to just use
operands[0] (casting it to the right size with subreg:SI, if needed) to avoid
using a potentially-reserved hardreg. This would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #12 from Alexander Monakov ---
> Do you have anything in particular in mind?
I mostly wonder why does sh.md change RTL representation of a sibcall that way,
instead of simply generating the required relative address load upfront,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #2 from Alexander Monakov ---
(added SH maintainers, Oleg Endo and Kaz Kojima to Cc)
In response to the last sentence in my analysis, on IRC Rich pointed out that
using r1/r2/r3 should be better that r0 because some instruction can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #7 from Alexander Monakov ---
Oleg, Rich, there's some confusion in comments 4-6. Please unwind all the way
back to comment #1, and let me explain the issue once again. I now see that my
phrasing back then was insufficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #8 from Alexander Monakov ---
Hm, if GCC won't accept clobbering a hardreg that overlaps the output hardregs
holding the return value (operands[0]), then it's less obvious. r0 is always
suitable then and does not require mentioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
--- Comment #30 from Alexander Monakov ---
Nick, can you please post the patch to gcc-patches too, to avoid confusing
future people who wouldn't be able to find the explanation of the patch in the
archives?
(did you get approval for this patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090
--- Comment #5 from Alexander Monakov ---
Ilya, 'omp declare target' is not applicable to arrays with automatic storage,
is it? The array needs to be either global, or have the SAVE attribute (similar
to 'static' keyword for local vars in C) —
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Compiling and running the following testcase with non-shared-memory accelerator
segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090
--- Comment #2 from Alexander Monakov ---
I've assigned 'fortran' category to the bug because "allocatable arrays" are
specific to Fortran, and the gfortran front-end already does some processing of
allocatable arrays for OpenMP directives. I
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
When multiple OpenMP reductions are specified, GCC
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #7 from Alexander Monakov ---
I have filed this issue previously as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 (unfixed, has minimized
repro). A workaround on gcc side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
Alexander Monakov changed:
What|Removed |Added
CC||kfischer at college dot
harvard.ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65099
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-w64-mingw32
Created attachment 35846
-- https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
--- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org ---
In that case I'd like to contribute a documentation patch to make that clear in
the pure/const attribute information, but I need more explanation. I see that
int p(void
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
The following testcase:
int p(void) __attribute__((const));
void g(int);
void f()
{
for (;;)
g(p());
}
is optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #5 from Alexander Monakov amonakov at gcc dot gnu.org ---
Author: amonakov
Date: Mon May 11 16:10:24 2015
New Revision: 223005
URL: https://gcc.gnu.org/viewcvs?rev=223005root=gccview=rev
Log:
PR target/65753
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org ---
The check rejecting indirect calls was introduced with commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=069db0ae0a5b5b61d64731a94eea002fb3c9d901
(gcc-patches thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org ---
For a simpler testcase:
void g(void (*f)(void))
{
f();
}
gcc/cc1 -fPIC -O2 -m32:
g:
subl$12, %esp
call*16(%esp)
addl$12, %esp
ret
Here %ebx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org ---
Example testcase:
void *lookup_f(void);
void g()
{
void (*f)(void) = lookup_f();
f();
}
With -O2 -fPIC, on x86-64 GCC produces the desired tail call:
g:
subq$8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org ---
Bug 64420, which was marked as a duplicate, presents an example where there's
no diagnostics at build time (linking succeeds), but the resulting code is
wrong and will fail
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Minimal testcase:
$ cat test.c EOF
#ifdef USE_ASM
void *f_resolver() asm(f);
asm(.type f, %gnu_indirect_function);
void *g_resolver() asm(g);
asm(.type g, %gnu_indirect_function);
#else
int f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
CC||amonakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
CC||amonakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Attachment #32830|0 |1
901 - 1000 of 1128 matches
Mail list logo
