https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #11 from David ---
(In reply to Ciro Santilli from comment #10)
> If I do start work, I'll ping here to avoid work duplication.
Do. I have some resources I could email you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #9 from David ---
(In reply to Ciro Santilli from comment #8)
- I haven't posted a patch file since I wasn't sure that I was all that close
to being done. But I'm certainly not opposed to the idea. Were you
volunteering to move thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #7 from David ---
(In reply to ktkachov from comment #6)
> I think David (CC'ed) was interested in this?
Well, the news here is mixed.
While I attempted to write this (see
https://www.limegreensocks.com/arm/Extended-Asm.html#AArch64O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68610
--- Comment #2 from David ---
Yes, this still occurs with trunk Revision 239974. I'm using MSYS2 under
Windows and my current configure line is:
../gcctrunk/configure --enable-languages=c,c++ --target=x86_64-w64-mingw32
--build=x86_64-w64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #8 from David ---
I doubt this patch is ever going anywhere. Now that v6 has shipped, producing
an error for both using and clobbering flags would "break backward
compatibility." On the plus side it would probably have caught your i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43319
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39440
--- Comment #5 from David ---
This is a duplicate of 30527.
A subset of the most commonly needed/used modifiers have been added to the docs
as of 5.x (including the %c0 referenced above). For this reason, I recommend
this bug be closed.
If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #14 from David ---
I understand that stage 3 is now closed too. I don't have svn write access, so
I can't check this in myself.
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
While this is a problem with inline asm, it seems like it would be
target-specific which is why I set component: target.
I can produce the problem several ways. This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #6 from David ---
Created attachment 37621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621&action=edit
Patch for missing clobber validations
I have created a patch (attached) that does the check I am describing. And
while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69562
David changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
Building gcc trunk (232969) on cygwin64 using this config line:
/cygdrive/c/cygwin64/src/gcc-trunk/configure --enable-languages=c,c++
--disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
--- Comment #7 from David ---
Would a doc patch be appropriate too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68843
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
I was trying to figure out why I was getting this warning from ssp.c in libssp
when building gcc on i386:
warning: visibility attribute not supported in this configuration; ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61692
--- Comment #4 from David ---
(In reply to m...@gcc.gnu.org from comment #3)
> This test case isn't portable. If upped to 40 then it would be more
> portable.
What platform supports more than 30 operands?
As near as I can see, MAX_RECOG_OPERAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #5 from David ---
> the target code adds a cc clobber always.
Agreed. On i386, there is no way to say that an extended asm doesn't clobber
"cc", so it only serves as a comment on that specific platform.
> There is no conflict.
I b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #13 from David ---
Rumor has it that Phase 1 may be closing soon. Is there something else I need
to do here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #3 from David ---
> "=@ccc"(r) does not output to the "cc" register, it
> outputs to a general register.
Actually, I don't believe it does.
In v5, you *did* have to use "setc %0" with a general register AND it generated
an extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10396
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #1 from David ---
On further reflection, perhaps the best solution is even simpler.
It is my understanding that the "cc" clobber is redundant. Internally, the
flags are clobbered whether you set this or not. And I can't see how thi
inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
Normally when trying to use a register and clobber it at the same time, the
compiler kicks out an error (operand has impossible constraints). However th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68014
David changed:
What|Removed |Added
Severity|minor |enhancement
--- Comment #1 from David ---
In fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68084
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
David changed:
What|Removed |Added
Attachment #33302|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #10 from David ---
(In reply to Kai Tietz from comment #5)
> This patch is clear stage 1 material.
We're in stage 1. Is it time?
The patch adds the memory clobber, but I think the conclusion here was to
remove __gthr_i486_lock_cmp
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
This code:
#ifndef __GCC_ASM_FLAG_OUTPUTS__
#error Not Defined
#else
int main()
{
int x;
asm volatile("# %0" : "=@ccc"(x));
}
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Target Milestone: ---
When compiling this code:
void f(void)
{
int foo asm("myfoo") = 42;
}
using: gcc -c sta7.c
I (correctly) get the warning message:
warning: ignoring asm-spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #16 from David ---
I've tried it now and it seems to do good things. This code:
int main(int argc, char *argv[])
{
char x;
asm("setc" : "=@ccc"(x));
if (!x)
return 6;
else
return argc;
}
produces this outp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #14 from David ---
(In reply to Jeremy from comment #12)
> It probably does a setcc on x86 which doesn't really gain much
I don't have a 6.0 build to test with yet, but I don't believe that's quite
correct. Looking at the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #11 from David ---
Apparently this feature has been checked in:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #10 from David ---
There was some discussion of this on the gcc mailing list. Not sure what
became of it: https://gcc.gnu.org/ml/gcc/2015-05/msg6.html
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Trimming the code down to minimal:
int main()
{
int lo;
for(int x=0; x < 10; x++)
{
asm ( "# asm here" : "=r" (lo));
}
return lo;
}
Compile wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
--- Comment #7 from David ---
While I don't yet see a case here to justify making this change generally, it
may be useful to change this for private builds of gcc. For those cases,
change this line in gcc/genconfig.c:
max_recog_operands = 29;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #8 from David ---
(In reply to Kai Tietz from comment #7)
The first code block in comment #6 is what is in the code now. As you can see,
it already has the #define you are describing. I don't understand what you
mean by "change it t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #6 from David ---
Actually, the code already uses InterlockedCompareExchange. UNLESS users
explicitly tell it not to:
#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
static inline long
__gthr_i486_lock_cmp_xchg(long *__dest, long __xch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #4 from David ---
(In reply to Mikael Pettersson from comment #3)
> Do you have a test case which fails without your patch?
I do not. But this is a "by definition" thing.
This instruction is intended to emulate the Windows Interloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61740
David changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61692
David changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #2 from David ---
Attaching a patch was just the clearest way I knew to show the problem.
My hope was that posting it here would allow someone who knew how to submit
patches to take this the rest of the way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64681
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900
--- Comment #5 from David ---
I agree that the benefit for 3 bytes isn't going to be a big win. And
certainly this sample, created from scratch solely to illustrate the problem,
can be better written.
For a more real-world sample, how about s
: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Using a constraint like this:
"=m" ( *(struct { char __x[BUFSIZE]; } *)b)
only works for very specific sizes of BUFSIZE (1, 2, 4, 8, 16). All other
sizes (3, 12,
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Created attachment 33302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33302&action=edit
Update __gthr_i486_lock_cmp_xchg to add memory clobber
InterlockedCompareExchang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
--- Comment #2 from David ---
Sent July 9, 2014: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00604.html
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Created attachment 33087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33087&action=edit
Proposed patch
The attached patch fixes 4
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
There is an ICE coming from recog.c in extract_insn. The problem occurs when
you have 30 inputs and 1 goto in an asm instruction. That'
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Created attachment 33037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33037&action=edit
Proposed patch
There is a problem in ia32intrin.h. Extracting bits of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
--- Comment #8 from David ---
I can confirm what Kai had to say in comment 7. Using a newer build resolves
both the original problem reported by Jakub and the problem I saw in comment 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39440
David changed:
What|Removed |Added
CC||gccbugzilla@limegreensocks.
|
55 matches
Mail list logo
