[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 libgc
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 do
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
libu
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 th
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 adv
On 02/25/2010 08:07 AM, Uros Bizjak wrote:
On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill 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 i686-pc-linux-gnu d
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 t
>> 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
On 02/17/2010 04:41 PM, Joern Rennecke wrote:
Quoting Ralf Wildenhues :
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 commas.
+ $[]as_decl_type
On 02/16/2010 05:14 PM, Richard Guenther wrote:
On Tue, Feb 16, 2010 at 4:59 PM, Paulo J. Matos 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 ideas when this is goi
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
wrote:
>
>> On 02/08/2010 09:58 AM, Joern Rennecke wrote:
>>>
>>> That would only work if every program that uses libiberty uses
>>>
On 02/02/2010 05:04 AM, Michael Witten wrote:
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini
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 about the tangled mess th
On 01/26/2010 08:57 AM, Paolo Bonzini wrote:
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
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 it
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 03:04 PM, Joern Rennecke wrote:
Quoting Christian Joensson :
-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
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 grant
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
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 current
On 01/09/2010 04:48 PM, H.J. Lu wrote:
On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzini 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).
Not knowing a
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 o
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 comb
On 12/23/2009 06:47 PM, H.J. Lu wrote:
On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini 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? Can't we ma
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 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 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 of
On 12/23/2009 01:01 PM, Steven Bosscher wrote:
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei 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 doesn't because it ma
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
regi
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"
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 s
On 12/19/2009 01:07 AM, Joern Rennecke wrote:
Quoting Michael Eager :
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 quite work right yet,
On Thu, Dec 17, 2009 at 19:54, Eric Botcazou 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 results in favor
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,
http://embed.
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 t
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 these
On 11/30/2009 09:47 PM, Michael Witten wrote:
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI 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 to be
a hard requiremen
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 patc
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/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/[ \t]*$//
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 target
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/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
port
On 11/13/2009 12:43 PM, Paul Edwards wrote:
I normally define PREFIX in a
common header file. However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword.
regex.c is forked from anything else, so I don't think a patch changing
PREFIX to FUNC_PREFIX will hav
On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote:
From: "David Edelsohn"
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 correctly detects tha
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 you'
Possible 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 seq is 1 to 1
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 ad
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
On 10/19/2009 10:48 AM, Richard Guenther wrote:
On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill
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 indicates
4.3.4, 4.4.1, and the
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
-Winline doesn't help here. Scanning the assember output does (obviously!).
nm also does.
Paolo
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 branch
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 con
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
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, sizeof.
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 09/29/2009 06:52 PM, Ian Lance Taylor wrote:
Paolo Bonzini 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 host libiberty
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 host libiberty?
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/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/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 plugin.c
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. H
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!
Paol
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 a
On 09/20/2009 06:31 PM, Richard Guenther wrote:
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab 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 especially if the con
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 re
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 re
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 )2006-1
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 p
On Fri, Sep 4, 2009 at 16:35, Stefan Dösinger 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 function has the
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
arriv
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
#include
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 main(
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. M
On 09/03/2009 12:27 AM, Kai Tietz wrote:
2009/9/3 Paolo Bonzini:
if (TARGET_64BIT
? !is_attribute_p ("msvc_prologue", name))
: is_attribute_p ("msvc_prologue", name))
{
warning (OPT_Wattributes, "%qE attribute not available for "
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 b
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 ord
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 tr
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 alter
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 is
When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of spil
Patterns should not include the separator (unless escaped), even
as part of a character class. In conformance with Posix, the Cray
`sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
[...]
Portable `sed' regular expressions should use `\' only to escape
characters in the s
On 08/26/2009 12:48 PM, Dave Korn wrote:
Dave Korn wrote:
Also please single-quote the commands.
Ok, why?
BTW should I do that for all four of the patterns? And what about $dirname
and $basename, and the couple of dozen other locations in ltmain.sh that use
quoted sed scripts? (You
On 08/26/2009 12:38 PM, Dave Korn wrote:
Oops. Looks like there are different versions of SED that have different
requirements, because on cygwin SED 4.1.5, you*have* to quote the comma in
the curly-braces {min,max} repetitions specifier or it is interpreted as a
separator.
Right. I also
Argh. Very sorry for the breakage, I'll get straight onto it. What
versions of the mingw+msys tools are you using? Can you please send me a copy
of the generated libtool script, and the output you get when re-running the
failing libtool command manually after adding the "--debug" (non-modal)
On 08/21/2009 10:52 AM, Laurynas Biveinis wrote:
Trees and rtxes mostly. I haven't got around to taking a closer look,
but for example folders love allocating temporary trees. For example,
in tree-ssa-ccp.c:fold_gimple_assign,
if (COMPARISON_CLASS_P (op0))
{
1) Stop abusing current GC by allocating structures there that GC
knows nothing about, i.e. there is never a path from GC roots to any
variables of that type and so gengtype does not produce markers it.
That's good.
BTW, it does not deal with types that in some instances have variables
alloc
My experience is that fold-const.c requires 20 MB of memory (not
including the size of the executable) to compile with -Os. That's
the biggest.
Is that typical/expected?
It doesn't seem too big.
Because it just occurred to me that maybe the lack of a "normal"
implementation of alloca() is cau
On 08/17/2009 03:33 PM, ami_stuff wrote:
-m68060 -O3 -fno-unswitch-loops
and
-m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize
-fpredictive-commoning
Some heuristics are tuned differently for -O2 and -O3. The only way to
know is to look at the dumps.
Paolo
On 08/17/2009 02:32 PM, ami_stuff wrote:
Hi,
Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3
but not with -O3 -fno-unswitch-loops.
This one works for me too.
Could you try to compile "deflate.c" from libz?
Here are my results:
-m68060 -O3 -fno-unswitch-loops
On 08/16/2009 06:02 PM, Martin Guy wrote:
Yes, GCC is bigger and slower and for several architectures generates
bigger, slower code with every release, though saying so won't make
you very popular on this list! :)
But surprise, if you report a bug, chances are it will be fixed
(especially for
I chose to define Pmode as PDImode, and write PDI patterns for pointer
moves & arithmetic. POINTER_SIZE is 64 bits, UNITS_PER_WORD is 4.
FUNCTION_ARG_ADVANCE arranges for both SImode and PDImode values to
occupy a single register. I have the port mostly working (passes 90% of
execution tests), b
Ok, after a few false leads, I found something that produced a
pleasing result. Fantastic I should say!
With this mod:
C:\devel\gcc\gcc>cvs diff debug.c
Index: debug.c
===
RCS file: c:\cvsroot/gcc/gcc/debug.c,v
retrieving revision 1
In any case, if you build with -g and use in addition the "debug
assembler output" flag -dA the assembler output should contain
human-readable comments containing line number information.
Regardless, if line number notes are interspersed in the stream,
maybe whenever I write out an assembler i
On 08/03/2009 03:52 PM, Unruh, Erwin wrote:
2) Is this a bug?
I think it's a bug in the specification.
User-specified CFLAGS are always passed last in the Makefiles (at least
for Automake, but it is a good practice in general) so that the user can
override options like -D, -U, -O, -g, -f, -m
Tom> I looked into this a little. It looks like the PPL checks don't work
Tom> properly in the case where PPL is a system library. I guess I need
Tom> --with-ppl=/usr ... I will try that later.
I don"t know really how to fix that quickly! I must confess that
autoconf related files in GCC scare
201 - 300 of 1076 matches
Mail list logo
