On 04/26/2010 11:23 AM, Mark Mielke wrote:
Personally, this whole issue is problematic to me. I really can't see
why I would ever sue somebody for using software that I had declared
free.
Because (a derivative of) it is being made nonfree?
It wouldn't be worth my time and I have trouble
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've had about as much
luck getting the patch to fix this...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
Sorry if I haven't reviewed
Well your review does pretty much amount to because darwin lacks
objdump like linux, the patch is rejected
Please reread.
Paolo
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewarde...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a
On 04/21/2010 07:42 PM, Jack Howarth wrote:
However in the past when I submitted patches for areas outside
of the darwin specific source files, they were rejected*if* they
made the code too darwin-centric.
Well, in this case I gave you a suggestion, so it was implicit that I'd
have approved
On 04/21/2010 07:51 PM, Jack Howarth wrote:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
/usr/lib64/libsqlite3.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab sch...@linux-m68k.org wrote:
Paolo Bonzini bonz...@gnu.org writes:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
Paolo,
We don't have -D in our nm. How about the following change to
configure.ac?
Ok. See? ;-)
As a followup, if you have access to a Linux machine you can try
removing the objdump requirement altogether.
(Thanks Eric too).
Paolo
This revised patch builds plugin support fine on x86_64-apple-darwin10 and
x86_64 Fedora 10...
Ok for trunk and 4.5 branch after a few days.
Paolo
On 04/14/2010 03:36 PM, Jack Howarth wrote:
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote:
Hi Steven,
FWIW, this sounds great and all... but I haven't actually seen any
comparisons of GCC vs. LLVM with DragonEgg. A search with Google
doesn't give me any results.
Can you point
On 04/11/2010 06:26 PM, Duncan Sands wrote:
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end.
LLVM makes pretty aggressive deductions when it sees undefined
behaviour
These do not seem to point at LLVM's optimizer
On 04/11/2010 06:50 PM, Dave Korn wrote:
Grepping the -patches archives to see which platforms submitted
patches get testing on would also be interesting, but somewhat
harder owing to the more free-form nature of the text there. Still,
a two-to-one ratio of linux to rest-of-the-world would be
On 04/12/2010 04:18 PM, Dave Korn wrote:
Could anyone really believe that without being a grade A tinfoil-hat
wearing crazy? More precisely, could anyone capable of the kind of
rational thought processes that they'd need to have in order to be
able to make any kind of contribution to the GCC
On 04/13/2010 07:14 PM, Jack Howarth wrote:
Paolo,
I hope you don't think I was trolling in my initial post. Assuming
plugins will eventually be welcomed into the FSF gcc source tree in
general, there is a valid argument for having dragon-egg present with
a configure option that builds it if
On 04/13/2010 09:16 PM, Jack Howarth wrote:
Paolo,
It is unclear to me what the original intentions were when the
plugin infrastructure was created. That is, was it envisioned that
FSF could accumulate the plugins directly in the source tree to
ensure they were well maintained across FSF gcc
On 04/07/2010 06:17 PM, Gary Funck wrote:
We have access to only a few of the listed platforms,
(and in the case of IA64 the underlying OS is SuSE not
unknown-linux-gnu).
That does not matter. You're obviously not required to use Linux From
Scratch. :-) If you run ./config.guess from the
On 03/31/2010 11:25 AM, Vincent Lefevre wrote:
On 2010-03-31 11:04:03 +0200, Marc Glisse wrote:
IMHO this transformation mostly makes sense for the
-ffinite-math-only case where you can replace: put a constant and
multiply/divide by put a constant and add/sub and never care
about extracting the
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose they are not exported.
Richard.
Richard,
Shouldn't these still show up in the output from...
nm
On 03/31/2010 06:00 PM, Jack Howarth wrote:
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose
On 03/31/2010 06:24 PM, Jack Howarth wrote:
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose
On 03/25/2010 12:31 PM, Eric Botcazou wrote:
The combine pass had been written at least a decade before vector modes were
introduced so it essentially doesn't expect them, i.e. some transformations
simply don't make sense for vector modes. You need to analyze the one you're
seeing (e.g. where
On 03/05/2010 05:03 PM, Joseph S. Myers wrote:
I don't know if there's an existing free software implementation of UAX#14
(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be
the very heavyweight approach.
Yes. You can get it from gnulib like gdb does, or you can link
On 03/01/2010 09:48 PM, DJ Delorie wrote:
But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
Is it still used outside
On 02/25/2010 08:07 AM, Uros Bizjak wrote:
On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrillja...@redhat.com wrote:
On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
On Thu, 18 Feb 2010, Jason Merrill wrote:
I periodically get bitten by bug 34115: a compiler configured without
--with-arch on
On 02/25/2010 08:51 AM, Arnaud Charlet wrote:
The main mangling (in Ada parlance, we talk rather about encoding)
that is performed by GNAT is to handle packages (namespace in C++) and
to differentiate overloaded functions (and there, a simple counter is all
that is needed).
One of the
This will probably break building glibc, as problems building when __i686
is a predefined macro have been known since at least 2002 but none of the
many patches proposed since then have been accepted.
I imagine changing the default would help with that...and packagers can
work around it.
I
On 02/17/2010 04:41 PM, Joern Rennecke wrote:
Quoting Ralf Wildenhues ralf.wildenh...@gmx.de:
sed alternation \| is not portable.
I've replaced it now with a pair of substitutions. I also fixed
the ',' substitution to give yield on opening bracket for the next cast,
and to apply for all
Maybe we can use this in AC_CHECK_DECLS instead of having a new
separate macro. If there is a parenthesis in the name call the new
version, if there is none, call the old one.
You shouldn't need to keep the old version around, it's supposed to be
a drop-in replacement. The reason I used a
On 02/16/2010 05:14 PM, Richard Guenther wrote:
On Tue, Feb 16, 2010 at 4:59 PM, Paulo J. Matospocma...@gmail.com wrote:
Hi,
From http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html
I get that 4.3.5 should come out after 4.4.2, however, 4.4.2 has come
and gone (with 4.4.3) and no 4.3.5.
Any
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
On Tue, Feb 9, 2010 at 02:17, Joern Rennecke
joern.renne...@embecosm.com wrote:
On 02/08/2010 09:58 AM, Joern Rennecke wrote:
That would only work if every program that uses
On 02/02/2010 05:04 AM, Michael Witten wrote:
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini paolo.carl...@oracle.com
wrote:
it's extremely unlikely that the C++ front-end maintainers could
even consider reviewing patches from a novice for such an hard to
implement feature.
That says more
On 01/25/2010 03:04 PM, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Ok.
Paolo
This probably is a new version of PR41418 then. We have the problem that
fortran is turned on in --enable-languages, so libgomp configure expects the
fortran compiler to be available.
Does this fix it for you?
Index: configure.ac
On 01/25/2010 11:38 PM, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran compiler to be available.
Does this fix
I think the main reason is that DMD front end sources are dual licensed
with GPL and Artistic License. The DMD backend is not under an open
source license (personal use only), so the Artistic License is how the
two are integrated. The fork is required to allow DMD to continue under
its
On 01/23/2010 04:29 PM, Richard Guenther wrote:
We could warn about this when building with C++ but with C we do not
see bools but ints here.
With such a warning there would be no reason not to build stage2 and
stage3 with bool == _Bool.
Paolo
Strictly speaking, that's not true. Even if the submitter would still
be required to have copyright assignment for the FSF, they could be
copyable to the DMD front-end _as long as the submitter himself sends
them for inclusion there too_. This is the practical significance of
the license
On 01/09/2010 12:16 PM, Steven Bosscher wrote:
This is with gcc SVN revision 155740, and src checked out yesterday
(top of src/Changelog is the fix from Kaveh and FX for gcc PR42424).
Not knowing a thing about libtool, I hope someone can tell me what's
wrong here;-)
src and gcc's libtool are
On 01/09/2010 04:48 PM, H.J. Lu wrote:
On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzinibonz...@gnu.org wrote:
On 01/09/2010 12:16 PM, Steven Bosscher wrote:
This is with gcc SVN revision 155740, and src checked out yesterday
(top of src/Changelog is the fix from Kaveh and FX for gcc PR42424).
On 01/03/2010 11:25 PM, Richard Guenther wrote:
char charray[sizeof(long)] = {...};
long l = *(long*)charray; // ok
not correct;) (the lvalue has to be of character type, yours is of
type 'long' - the type of the actual object does not matter)
What would be correct instead is
There are some other quirks with the MicroBlaze architecture.
The cmp/cmpu instructions only take a register. Other instructions
which can be used for equality or signed comparisons (xor or sub)
can take an immediate operand. I'll see how they can be added.
You can probably convince combine
On 12/21/2009 08:10 PM, Richard Henderson wrote:
(define_insn_and_split *cmp
[(set (match_operand:SI 0 register_operand =r)
(lt:SI (match_operand:SI 1 register_operand r)
(match_operand:SI 2 register_operand r)))]
cmp %0,%1,%2\;andi $0,$0,1
[(set
On 12/22/2009 07:24 PM, Jeff Law wrote:
On 12/22/09 11:16, Andrew Hutchinson wrote:
I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
(set (reg:QI 25 r25 [+1 ])
(subreg:QI (sign_extend:HI (reg:QI 49)) 1))
The sign extension is completely redundant - the upper part of
On 12/23/2009 01:01 PM, Steven Bosscher wrote:
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Meib...@broadcom.com wrote:
Hello,
I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
I think this could be fixed if fwprop propagated addresses into loops;
it
On 12/23/2009 03:05 PM, Joern Rennecke wrote:
So if this is only useful for a limited set of targets, why isn't it
controlled by an option or a target hook so that it is only turned on
on the targets where it is deemed to make sense overall?
Well, this optimization is basically the opposite
On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
this should be fixed? Or it requires extra patch?
No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
properly for your target), we could fix this very easily.
Paolo
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Paolo
On 12/23/2009 06:47 PM, H.J. Lu wrote:
On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzinibonz...@gnu.org wrote:
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Is there a bug open for x86?
On 12/17/2009 06:17 PM, Richard Guenther wrote:
It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
use
__builtin_trap ();
instead for the whole sequence (the unreachable is implied then).
GCC choses a size-optimal trap representation for your target then.
Agree that it
On 12/19/2009 01:07 AM, Joern Rennecke wrote:
Quoting Michael Eager ea...@eagercon.com:
Hi --
I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.
In theory cstore / cbranch should be the future, but the last time I tried
to use them, they didn't
On Thu, Dec 17, 2009 at 19:54, Eric Botcazou ebotca...@adacore.com wrote:
However I would prefer to leave these testcases in, unless there is a
strong feeling that they are too distracting. They serve as poignant
little reminders about how easy it is to get volatile wrong...
They skew the
On 12/16/2009 03:21 AM, John Regehr wrote:
Hopefully the results are more fair and useful now. Again, feedback is
appreciated.
I would also avoid testcases using volatile. Smaller code on these
testcases is often a sign of miscompilation rather than optimization.
For example,
On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way
I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch
the 'CC1000SendReceiveP*' definitions because they are not static
(unless he explicitly built with an export map).
Interesting.
I haven't analyzed what is going on in
On 11/30/2009 09:47 PM, Michael Witten wrote:
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZIgh...@caip.rutgers.edu wrote:
The patch which makes the MPC library a hard requirement for GCC
bootstrapping has been approved today.
Out of curiosity and ignorance: Why, specifically, is MPC going
On 11/27/2009 03:21 PM, Dave Korn wrote:
you and Paolo are pretty much the only
people who feel that it should have been backed out
Uh? I said that the repository should have been made readonly if there
was a concrete possibility of backing out the patch, be it with svn cp
(which we already
On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more elaborate preserving a fixed number of
leading blanks dependng on the
On 11/25/2009 08:38 PM, Richard Guenther wrote:
If you can offer advice on how to teach quilt
(which I belive uses patch) to ignore whitespace changes when
applying patches then more power to you - the only tool that
seems to be able to ignore whitespace changes is diff.
sed -i '/^-/s/[
On 11/25/2009 06:45 PM, Dave Korn wrote:
Michael Matz wrote:
Someone with the appropriate rights needs to shutdown the svn server so
that no additional commits can be done, then the revision files in
db/revs/ and db/revprops/ starting with the wrong revision need to be
removed, then db/current
On 11/22/2009 10:48 AM, John Nowak wrote:
Hello. I would like to get the necessary forms for copyright assignment
to GCC for future work on GNAT. I was told this is the way to kick off
the process.
I sent them offlist.
Paolo
On 11/23/2009 11:32 AM, Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them?
I think your best bet is to grep the changelogs for what has changes,
and see what was done for other ports. Many
On 11/14/2009 12:27 PM, Paul Edwards wrote:
So what I have done is get the compiler to fail on any missing
prototype. I think perhaps we need to have a generic gcc or
autoconfigure option called config by prototype. MVS is just
one instance where you might wish to do it this way. Other
ports
On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote:
From: David Edelsohn dje@gmail.com
AIX Shell is KSH.
The problem is shell append += and libtool not running with the same
shell used by configure.
Hm, the mpc configure script actually has a check for shell +=, and on
my solaris box it
On 11/08/2009 10:29 PM, David Edelsohn wrote:
The problem is shell append += and libtool not running with the same
shell used by configure.
What version of libtool is used by mpc? Libtool HEAD could fix this bug.
Paolo
On 11/02/2009 08:49 AM, Joern Rennecke wrote:
This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or
li value=110Possible special combination pattern: If the two
operands to a comparison die there and both come from insns that are
identical except for replacing one operand with the other, throw away
those insns. Ok if insns being discarded are known 1 to 1. An andl
#1 after a
Hi all,
with the new plugin infrastructure, it makes sense to replace the
one-catches-all md reorg pass with target-specific passes plugged into
the pass manager.
If the md reorg is doing just complex peephole optimizations that cannot
be achieved with targets, that's fine.
This has the
On 10/19/2009 10:48 AM, Richard Guenther wrote:
On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:
Hi,
I got a random unsolicited email about arc-elf since
I pop up in google a lot asking cross compiler questions.
I decided to try to build it and as PR41747
On 10/22/2009 01:57 AM, Ian Lance Taylor wrote:
See cfg*.[ch] and df*.[ch]. Note that df*.[ch] only applies to RTL.
There is no clean way to extract the dependency information.
On trees, the SSA def-use edges could be seen as (well, are) a DFG.
Paolo
-Winline doesn't help here. Scanning the assember output does (obviously!).
nm also does.
Paolo
We should also keep in mind that such logs aimed at users should support
i18n - unlike the existing dumps for compiler developers, which are quite
properly English only, and most calls to internal_error which should only
appear if there is a compiler bug and are also only meant to be useful for
That exactly is the problem. You can't have a CONST_INT inside a
ZERO_EXTEND. That is not valid.
You'll need a separate pattern to recognize the CONST_INT without a
ZERO_EXTEND around it. Unfortunately, this will not give reload
the freedom it should have.
You mean I should remove the
On 09/25/2009 09:35 PM, Joseph S. Myers wrote:
Viewing deleted files and their history (and for SVN deleted branches are
just a special case of deleted files) is something SVN is bad at since you
do need to work out the last revision the file was present first.
Yep. Anyone deleting dead
The function SetCategory(v) returns void and simply assigns
the value of v to a class member, so there are no trap conditions.
TA, on the other hand, stands for trap always, so the condition
code is unimportant anyway. Why has the trap instruction been generated?
Usually this is because you
On 10/05/2009 09:29 PM, Sergey Sadovnikov wrote:
Can anybody explain why line marked with '{*1}' produce this error
message:
I think it's because there is no constructor for array that takes an
initializer_list. I get this message if I change your {*2} line to:
std::array wchar_t,
On 10/01/2009 11:37 PM, Sriraman Tallam wrote:
Hi,
I moved implicit-zee.c to config/i386. Can you please take another look ?
I think this patch is best reviewed by an x86 backend maintainer now.
Thanks for doing the adjustments, BTW.
Paolo
My question is my definition of strict correct?
or should it be reload_in_progress || reload_completed?
This is not my area of expertise, but reload_completed is definitely
too weak.
I actually think strict should always be true when testing for
satisfaction of constraints.
Paolo
On 09/29/2009 06:52 PM, Ian Lance Taylor wrote:
Paolo Bonzinibonz...@gnu.org writes:
So all Diego needs to do is pass --enable-shared down to libiberty
when --enable-lto/--enable-gold. The way to do that is something like
the appended.
What about just always adding --enable-shared to the
On 08/08/2009 11:59 PM, Sriraman Tallam wrote:
Hi,
Here is a patch to eliminate redundant zero-extension instructions
on x86_64.
The code looks nice! However, since it is very specific to x86 (and x86
patterns), I'd rather see it in the i386 machine-dependent reorg pass.
Thanks!
On 09/24/2009 08:14 AM, Ian Lance Taylor wrote:
I don't agree with this. If we want this code to be x86_64 specific,
then it should be done by having the i386 backend add the pass to the
pass manager, much as plugins can add a pass. Adding stuff to
md-reorg is a step backward.
That's true.
On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
We already have the hooks, they have just been stuck in plugin.c when
they should really be in the generic backend. See register_pass.
(Sigh, every time I looked at this I said the pass control has to be
generic but it still wound up in
On 09/24/2009 02:41 PM, Mohamed Shafi wrote:
How can i overcome this error?
Remove the guilty alternatives, for example the d/L alternative, and
make operand 2 a register_operand.
Paolo
On 09/23/2009 10:44 AM, Yuri Gribov wrote:
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
Yes, it's possible that 64-bit ints
reg.field1 = val1, reg.field2 = val2;
would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.
You can also do the RMW yourself: declare the register volatile, but not
the fields of it, and copy in/out of the register manually.
volatile struct
On 09/20/2009 06:31 PM, Richard Guenther wrote:
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwabsch...@linux-m68k.org wrote:
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation
And http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
This one is relatively rare, so no. Feel free to pick up the patch, I
already have too many approved patches that I cannot get round to test
and commit.
Paolo
On 09/14/2009 02:13 PM, Ryan Mansfield wrote:
Paolo Bonzini wrote:
4) some might fall under 2 or 3. Actually just one; he used to be at
QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him:
gp (Graeme Peterson ) 2003-08-06 3
Graeme left QNX back in 2006. He removed himself
Hopefully the combined wisdom on this list can help getting this
addressed (one way or the other). :-)
I can see five cases:
1) Some of these have requested gcc.gnu.org access only to be
bugmasters, for example they have no commits.
dalecki (Marcin Dalecki )
On 09/06/2009 11:15 AM, Stefan Dösinger wrote:
Am Saturday 05 September 2009 17:08:19 schrieb Ross Ridge:
If this patch is essentially only for one application, maybe the idea
of implementing a more generally useful naked attribute would be the
way to go. I implemented a naked attribute in my
On Fri, Sep 4, 2009 at 16:35, Stefan Dösingerste...@codeweavers.com wrote:
Am Friday 04 September 2009 14:49:42 schrieb Stefan Dösinger:
I attached another version of the patch - I restarted the compile, so I
still don't know if it fully works.
Seems to be working - gcc compiles fine, my test
I guess the error isn't about the const_int 0, but about operand 0. Any ideas?
Yes, you need this:
[(set (match_operand:SI 0 register_operand =r)
(match_operand:SI 1 register_operand r))
(unspec_volatile [(const_int 0)] UNSPECV_VSWAPMOV)]
Paolo
Yes, you need this:
[(set (match_operand:SI 0 register_operand =r)
(match_operand:SI 1 register_operand r))
(unspec_volatile [(const_int 0)] UNSPECV_VSWAPMOV)]
That works, thanks!
I just found the =r and r stuff myself almost at the same time your mail
arrived. But
I don't know, I was just reworking Stefan's patch. He didn't include
function names (-p) in the patch so I don't know what function this is
part of.
It was ix86_handle_abi_attribute. I'm usually using git, and don't like cvs
and svn too much. It seems svn diff doesn't support a -p option here.
#includestdio.h
void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
b += a;
hook (a, b, a + b);
}
void qq (int a)
{
auto void q1 (int aa, int bb, int cc);
void q1 (int aa, int bb, int cc)
{
printf (%d %d %d\n, a, aa + bb, cc);
}
foo (a, a + 1, q1);
}
int
Currently I still have these problems:
*) There is apparently some plugin framework in the works. Can this
functionality implemented as a plugin?
No, plugins do not affect the backend.
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
Currently I pop %ebp after the 5
On 09/03/2009 12:27 AM, Kai Tietz wrote:
2009/9/3 Paolo Bonzinibonz...@gnu.org:
if (TARGET_64BIT
? !is_attribute_p (msvc_prologue, name))
: is_attribute_p (msvc_prologue, name))
{
warning (OPT_Wattributes, %qE attribute not available for
%d-bit,
On 08/31/2009 08:54 PM, Ralf Wildenhues wrote:
While still working to prove Bob wrong on the fixincludes sed issues,
Bob?
- require a better sed,
- split the script in two inside Autoconf (if $extrasub is nonempty),
- allow for extra sed scripts here.
Like a new variable $ac_presub, that
In fact, I think this API shouldn't be even more encouraged. It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).
I agree. However, I did not have any
On 08/31/2009 10:41 PM, Ralf Wildenhues wrote:
* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST:
In fact, I think this API shouldn't be even more encouraged. It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree
On 08/31/2009 11:11 PM, Ralf Wildenhues wrote:
The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2). Something like
AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
[more-init-cmds])
but then the
701 - 800 of 1512 matches
Mail list logo
