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
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://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
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
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
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=68095
--- Comment #6 from David ---
Created attachment 37621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621=edit
Patch for missing clobber validations
I have created a patch (attached) that does the check I am describing. And
while I was
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
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.
: 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=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.
|
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,
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
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
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=68014
David changed:
What|Removed |Added
Severity|minor |enhancement
--- Comment #1 from David ---
In
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #16 from David gccbugzilla at limegreensocks dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #14 from David gccbugzilla at limegreensocks dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #10 from David gccbugzilla at limegreensocks dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #11 from David gccbugzilla at limegreensocks dot com ---
Apparently this feature has been checked in:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#FlagOutputOperands
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 with: c++.exe -O2 -m64 -S loop.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
--- Comment #7 from David gccbugzilla at limegreensocks dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #8 from David gccbugzilla at limegreensocks dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436
David gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
CC||gccbugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #6 from David gccbugzilla at limegreensocks dot com ---
Actually, the code already uses InterlockedCompareExchange. UNLESS users
explicitly tell it not to:
#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
static inline long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #4 from David gccbugzilla at limegreensocks dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61692
David gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61740
David gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #2 from David gccbugzilla at limegreensocks dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64681
David gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
CC||gccbugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900
--- Comment #5 from David gccbugzilla at limegreensocks dot com ---
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
: 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, 1000, etc
: 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=33302action=edit
Update __gthr_i486_lock_cmp_xchg to add memory clobber
InterlockedCompareExchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
--- Comment #2 from David gccbugzilla at limegreensocks dot com ---
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=33087action=edit
Proposed patch
The attached patch fixes 4 inline asm
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's 31
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=33037action=edit
Proposed patch
There is a problem in ia32intrin.h. Extracting bits of the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
--- Comment #8 from David gccbugzilla at limegreensocks dot com ---
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 gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
CC||gccbugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39440
David gccbugzilla at limegreensocks dot com changed:
What|Removed |Added
CC||gccbugzilla
55 matches
Mail list logo
