On Fri, May 13, 2005 at 11:37:16PM +0800, zouq wrote:
> original program is:
> mul.d $f1, $f1, $f0
> add.d $f2, $f2, $f1
> div.d $f3, $f0, $f1;
>
> after i compile used my changed gcc, it becomes:
> madd.d $f2, $f1, $0
> div.d $f3, $f0, $f1
>
> as you can see, the value of $f1 is wrong!!
Check
On Fri, May 13, 2005 at 02:31:12PM -0400, Andrew MacLeod wrote:
> Is there code laying around I can snarf and work with?
See sched-vis.c.
r~
On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
> The documentation for -fvisibility=hidden suggets that this switch is
> useful for shared libraries, to make things smaller and faster. It
> doesn't seem to be appropriate for object libraries.
It's done *exactly* so that we catch th
On Sat, May 14, 2005 at 09:32:26AM +0800, zouq wrote:
> the MAX_INSNS_PER_PEEP2 is 3,
> when the program case is :
> mul.d $f1, $f1, $f0
> add.d $f2, $f2, $f1
> sub.d $f3, $f3, $f2
So what's the problem?
r~
On Sat, May 14, 2005 at 11:59:28AM +0200, Øyvind Harboe wrote:
> void test(void (*t)(void))
> {
> int i;
> for (i=0; i<10; i++)
> {
> t();
...
> int skip=0xdeadbeef;
>
> void do_goto (void)
> {
> goto l1;
> }
>
> test(do_goto);
...
> l1:
> if
On Sun, May 15, 2005 at 09:23:01AM -0600, Roger Sayle wrote:
> Probably the reason that fold_unary
> doesn't call fold_indirect_ref is precisely because it is unsafe.
Probably fold_indirect_ref way way way post-dates fold_unary.
r~
On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote:
> This is probably going to hurt, and will require things like using
> FIELD_DECL_ macros for FIELD_DECL's, TYPE_DECL_ macros for
> TYPE_DECL's, etc, instead of using DECL_ on both for some fields.
Can you be more specific on which fie
On Tue, May 17, 2005 at 02:10:48PM -0400, Daniel Berlin wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT, and my current thinking is that in a FIELD_DECL will
> be only accessible through DECL_FIELD_CONTEXT (unless we want to
> "re-merge" these two fields a
On Wed, May 18, 2005 at 05:12:09AM +0100, Sam Lauber wrote:
> I don't know about you, but forcing a link failure in good
> code just because someone screwed up GCC configuration is
> probably the of the most worst compiler hacker's sins.
But it IS NOT GOOD CODE! That's the whole point.
Whateve
On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
> What surprises me is that it's normally ok to mix static and shared
> libs, but not here. And the message is utterly uninformative about
> what is wrong or why the restriction exists.
It's been explained in detail many times before se
On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
> Fine, but are GCC *users* expected to search the GCC list archives?
If they want to know the answer to "why", as opposed to being
satisfied with "don't do that", then yes.
r~
On Wed, May 18, 2005 at 01:25:05PM +0200, Richard Guenther wrote:
>
> The following snippet
>
> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> (because calling an inline function does not mean the function
> needs to be separately compiled). */
>
On Wed, May 18, 2005 at 02:08:02PM +0200, Richard Guenther wrote:
> ! vtbl = build_fold_addr_expr (vtbl);
No convert.
And I'm pretty sure you never want to use convert, as that'll
emit warnings. Use fold_convert.
r~
On Wed, May 18, 2005 at 02:46:33PM +0200, Olivier Hainque wrote:
> A possible way to address that is to have expand_main_function compute the
> distance between the current and aligned values of the stack pointer (without
> touching it), and resort to allocate_dynamic_stack_space to allocate exactl
On Wed, May 18, 2005 at 11:10:42PM +0800, Ling-hua Tseng wrote:
> So I guess that there are some miss-configured in my ports, but I can't
> find it.
Put a breakpoint at tree-complex.c line 962. Examine the conditions
leading up to
if ((GET_MODE_CLASS (compute_mode) == MODE_VECTOR_INT
On Thu, May 19, 2005 at 04:58:32AM +0800, Ling-hua Tseng wrote:
> I got 4 lines "SI".
> (In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")
Then you need to debug your targetm.vector_mode_supported_p.
Starting around stor-layout.c line 1609:
for (; mode != VOIDmode ; mode =
On Thu, May 19, 2005 at 06:02:39AM +0800, Ling-hua Tseng wrote:
> struct gcc_target targetm = TARGET_INITIALIZER;
> ...
> #undef TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P unicore_vector_mode_supported_p
This is your bug. The TARGET_INITIALIZER needs to come last.
After three days of sequential bootstrap breakage, I'd like to propose
that mainline go into slush, wherein all these bootstrap problems, and
all the new testsuites failures get fixed. No other patches would be
allowed at all.
We'd unslush when the primary platforms have clean test results.
Thou
On Thu, May 19, 2005 at 10:11:54AM -0700, Mark Mitchell wrote:
> If you're running tests on a primary platform, and think things are OK,
> please send me an email pointing at gcc-testresults mail showing
> allegedly clean results for that platform *and* update:
>
> http://gcc.gnu.org/wiki/GCC%2
On Fri, May 20, 2005 at 07:41:53PM +0200, Jan Hubicka wrote:
> I am looking into that now. I would preffer the way of adding
> basic-block.h and friends into includes of insn-emit.c as in general I
> would like to make expanders/splitters/output templates aware of the
> profile (and thus BB they a
On Fri, May 20, 2005 at 09:40:11PM +0200, Jan Hubicka wrote:
> The problem with that is that I have to include rtl.h in cgraphunit and
> ipa-inline.c then as well. This is not much prettier either, but sure
> can do that if that sounds preferable.
Ug. Ok, leave it where it is and commit your pat
On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
The vectorization failures still need to be fixed.
r~
On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> Are these specific to SPARC?
No.
r~
On Sat, May 21, 2005 at 10:59:44AM +0200, Jan Hubicka wrote:
> I believe Andrew mentioned that there is a patch for this? (it is lack
> of sync in between operands and stmt itself)
The last state I saw is that the patch needed some minor updates.
I was hoping that one of the original authors woul
On Sat, May 21, 2005 at 10:46:19AM +0200, Eric Botcazou wrote:
> We have as initial RTL:
>
> (insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-stack-vars)
> (const_int -5120 [0xec00])) [0 S16 A128])
> (reg:TF 110 [ D.1221 ])) -1 (nil)
> (nil))
>
On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> Btw, is it me or the individual RTL dump options are broken?
The initial rtl dump is broken. The rest work.
I think one of Jan's IPA pass manager changes broke it.
r~
On Tue, May 24, 2005 at 07:17:22PM -0400, Daniel Jacobowitz wrote:
> $ORIGIN is nifty; but do you know how portable it is? I've got no
> clue.
Solaris and Linux only, afaik.
r~
On Wed, May 25, 2005 at 09:26:29PM +0200, Richard Guenther wrote:
> 1. There is already support for switching the ABI function-wise in
> the backend for local static functions. As a first step I'd like
> to expose this functionality as a function attribute.
Sure.
> 3. Emit calls to alt
On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
> static const double range = PI; // * 2.0;
> static const double incr = PI / 100.0;
The trig insns fail with large numbers; an argument
reduction loop is required with their use.
r~
On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote:
> I've never quite understood the necessity for performing trig operations
> on excessively large values, but perhaps my problem domain hasn't
> included such applications.
Whether you think it necessary or not, the ISO C functions
On Thu, Jun 02, 2005 at 11:21:31AM +0200, Richard Guenther wrote:
> During type checking of the middle-end in the tree-optimizers
> we run into type mismatches like
This isn't a type mismatch if the compatible_p langhook says
they aren't. Which I expect is true.
> question is can we / do we want
On Thu, Jun 02, 2005 at 08:46:25PM +0200, Richard Guenther wrote:
> Does it mean if the middle-end exchanges one
> type for the other there should be no observable effects (correctness
> wise) down the road?
Yes.
r~
On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote:
> * alpha*-*-unicosmk*
> No real update since 2002. If rth, the lone alpha maintainer, is actually
> maintaining it, I guess it should stay; it's not in bad shape. But does
> it really need fixproto?
This port was done by Ro
On Wed, Jun 08, 2005 at 06:36:49PM +0200, Richard Guenther wrote:
> now, with -mno-sse we have the following choices for call
> to function foo:
With -mno-sse and explicit use of sseregparm, error at compile time.
This is no different from any other ISA related compile time error
that we generate.
On Wed, Jun 08, 2005 at 12:50:32PM -0700, Steve Ellcey wrote:
> I noticed that vectors are always aligned based on their size, i.e. an
> 8 byte vector has an aligment of 8 bytes, 16 byte vectors an alignment
> of 16, a 256 byte vector an alignment of 256, etc.
>
> Is this really intended?
Yes.
On Fri, Jun 10, 2005 at 10:38:56AM +0200, Uros Bizjak wrote:
> To properly implement this switching scheme, I would like to ask, what is the
> proper way to check if MMX register is used as a parameter passing register in
> the call
CALL_INSN_FUNCTION_USAGE
> and how to check if MMX register is u
On Fri, Jun 10, 2005 at 10:50:01AM -0400, DJ Delorie wrote:
> typedef int __attribute__((section("foo"))) FOOINT;
>
> FOOINT a;
>
> Would it make sense to allow this sort of thing?
No more than it would make sense to have
typedef static int FOOINT;
IMO.
r~
On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote:
> This has a small flaw -- in case NODE has variable size, it gets
> allocated on stack dynamically, it may be allocated and deallocated
> several times, and its address is no longer an invariant.
>
> So I tried to fix the code as foll
On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:
> 1. For a bi-arch compiler for which 32-bit code is the default, we no
>longer need to override ASM_SPEC.
Well, this is the only way this patch applies, because...
> 2. We get earlier failure and better error messages from the as
On Mon, Jun 13, 2005 at 02:06:38PM -0500, Pat Haugen wrote:
> The following patch fixes the code to match the commentary of the algorithm
> such that block frequency is used instead of edge frequency.
Why? It seems to me that edge frequency is what's going to matter
to the cpu when considering th
On Mon, Jun 13, 2005 at 04:03:15PM -0400, Daniel Jacobowitz wrote:
> How would you feel about a patch that made us always pass --64
> as appropriate, at least if the assembler in question is gas?
I have no problem with that.
r~
On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote:
> OK, I remembered. I put
>
> if (is_gimple_min_invariant (t))
>
> or
>
> if (is_gimple_val (t))
> {
> shortcut;
> }
>
> type constructs on some places in gimplification.
With an aim toward speeding up gimplification, I gu
On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote:
> Or, if GAS can be told which mode it should be in via directives in
> its input (.code32/.code64?), then we could add something like
>
> fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32",
> asm_out_file);
>
> to x86_file_s
On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> >Any objections to adding Visual C++ style inline asms?
>
> Didn't RTH objected the last time?
One has to do a less gross job of it than Red Hat did. I suppose
I could be prodded int
On Tue, Jun 14, 2005 at 07:59:53PM -0400, Daniel Berlin wrote:
> Is this really supposed to look like this?
Not really. What's there is Good Enough (tm) if we immediately
expand to rtl; the union will Just So Happen to have Pmode, and
so things will Just So Happen to work.
This needs to use a V
On Wed, Jun 15, 2005 at 11:11:23AM +0200, Giovanni Bajo wrote:
> > This needs to use a VIEW_CONVERT_EXPR, at minimum.
>
> What about a compound literal instead?
I suppose. Why?
r~
On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
> ... because at least for the vector-shift case I need to
> check that the shift operand is constant, and only then return
> optab_shri/shli.
This isn't true. Just because the altivec patterns don't accept
anything other than a cons
On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
> Altivec does support non immediate shift amount (even if less efficiently -
> I have to put the shift amount in a vector register first). But since we
> have defined these optabs to represent shift operations that take immediate
> sh
On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
> The thought was to supply an API that would let the vectorizer ask for the
> minimal capability it needs - if all we need is a vector shift of a
> constant value in bytes, lets ask exactly for that, so that targets that
> don't suppo
On Sun, Jun 26, 2005 at 05:27:31PM +0200, Steven Bosscher wrote:
> The stuff added in 1.28 (lines 1608-1612) to kill early-clobbered
> operands is precisely the same as what is done just a few lines
> earlier (lines 1595-1598). Is this a thinko or is this necessary for
> some non-obvious reason??
On Mon, Jun 27, 2005 at 12:21:01PM -0700, Fariborz Jahanian wrote:
> FYI, the change to rtl in -O2 vs. -O1 is that -O2 includes -fforce-
> mem which forces memory operands to registers to make memory
> references common sub-expressions.
Hmm. I would suspect this is obsolete now. We'll have f
On Tue, Jun 28, 2005 at 11:59:15PM -0500, Steven J. Hill wrote:
> I have discovered what appears to be an optimization bug with '-Os'
> in GCC-4.1.0 for the MIPS architecture. It appears that functions
> which are declared as 'inline' are being ignored and instead turned
> into to function calls ..
On Wed, Jun 29, 2005 at 06:57:12PM -0400, Daniel Berlin wrote:
> I'm going to work around this by using TYPE_SIZE, but it would be nice
> if somebody could explain the purpose for this behavior (if it's a bug,
> i'll file a bug report). I would imagine we don't have truly empty
> things in C++, so
On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote:
> 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE
> to NULL before we call layout_decl on the parm and let layout_decl
> figure out what to do.
This is what relayout_decl does.
> 2. Add code in layout_decl to co
On Fri, Jul 01, 2005 at 09:27:48PM -0400, DJ Delorie wrote:
> Note that my complaint about the lack of endian support in that code
> still stands ;-)
I seem to recall running into this before. It's not a lack of
endian support, it's one piece lying to another about the size
of the object. Which
On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> I'm lost in the mysteries of expansion of the indirect call, also
> ix86_value_regno gets called all over the place, so the "interesting"
> call-site is hard to find.
We'll have to change the FUNCTION_VALUE interface to handle thi
On Fri, Jul 08, 2005 at 05:37:45PM +0200, Paolo Bonzini wrote:
> Also, here is some code that tries to load 1.0 into an SSE register
> without using the constant pool. I don't know if it is fast or not.
...
> pinsrwl $3, %1, %0" : "=x" (i) : "r" (0x3ff0));
No, this instruction is dreadfu
On Thu, Jul 07, 2005 at 05:30:26PM -0700, Dale Johannesen wrote:
> cvtss2sd[EMAIL PROTECTED](%ecx), %xmm0
>
> (this is Linux, the same happens on Darwin).
> This is not really a good idea, as movsd of a double-precision 1.0 is
> faster. The change from double to single precision
On Sat, Jul 09, 2005 at 07:48:47PM +, Thorsten Glaser wrote:
> Should I really not use -nostandardlibs for libgcc_s ?
Yes, I'm pretty sure you should not do that.
> I just got a linker warning because I had bumped libc
> from .36.1 to .37.0 and am recompiling gcc... this
> yields executables
On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:
> More appropriate would be to make the command line consistent with the
> code. If there's inline assembly that requires ev6, then -mcpu=ev6 is
> appropriate.
No, this code is protected by various system checks.
We want -mcpu=ev5 such
On Mon, Jul 11, 2005 at 08:57:58AM +0200, Falk Hueffner wrote:
> The "ldbu" instruction is only available on ev56 and above, however,
> gcc4.1 emits ".arch ev5" because of "-mcpu=ev5", which overrides as's
> "-mev6". This used to work because 4.0 didn't output ".arch ev5"
> because it doesn't actua
On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
> >No, this code is protected by various system checks.
> >
> >We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
> >but we require these specific instructions on specific ev56/ev6 systems
> >for i/o.
>
> rth, can you e
On Mon, Jul 11, 2005 at 10:20:08AM -0700, Dan Kegel wrote:
> Are you saying that __kernel_ldbu(mem)
> is never called on pure ev5 machines, then?
Yes, that is what I am saying.
r~
On Tue, Jul 12, 2005 at 10:58:17PM +0200, David Rasmussen wrote:
> Is this possible? Or is 32-bit and 64-bit entirely different "modes" on A64?
No it isn't possible. Yes, they are different modes.
r~
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
Speaking with the optimizer hat on, we *don't* do much optimiza
On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
> Issue 1.
> void Foo (char *ptr) {
> *(volatile char *)ptr;
> }
...
> char c;
> *(volatile char *)&c; // can this read be deleted?
...
> void Foo (volatile char *ptr) {
> *(char *)ptr;
I did see Ian's summary,
http://gcc.gnu.o
On Sun, Jul 17, 2005 at 09:18:01AM -0700, Ian Lance Taylor wrote:
> This is PR 22278. DannyB posted a simple, untested, patch here:
> http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
Thanks. I think Danny's patch attacks this too late. The
following patch appears to do the right thing with
On Sun, Jul 17, 2005 at 01:48:44PM -0400, Daniel Berlin wrote:
> As i expected, the sixtrack slowdown is entirely in global-alloc, in
> daten.f
>
> with -fno-tree-promote-statics
> global alloc : 0.23 ( 4%) usr 0.00 ( 0%) sys 0.24 ( 3%)
> wall 448 kB ( 3%) ggc
>
> without:
>
On Tue, Jul 19, 2005 at 10:31:13AM -0700, Steve Kargl wrote:
> Someone broke optimization of complex arithmetic. A 2005-06-01
> mainline gives the expected answer. A 2005-06-15 mainline is
> broken. I'll continue my binary search. Fortunately, building
> gcc on a dual opteron system with 12 GB
On Wed, Jul 20, 2005 at 06:26:03PM -0700, Dale Johannesen wrote:
> alignof doc has so many qualifications I'm not sure exactly what it's
> supposed to do.
__alignof__(double) == 8 on x86, regardless of command line
switches, because 8 is the *preferred* alignment of the type.
That's the weasel w
On Tue, Jul 19, 2005 at 10:46:34AM +0200, FX Coudert wrote:
> * builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins
> that C99 reserve for future use. Use it to define clog10, clog10f
> and clog10l.
Ok.
r~
On Tue, Jul 12, 2005 at 12:02:46PM +0200, Laurent GUERBY wrote:
> PR tree-optimization/22336
> * function.c (record_block_change): Check for
> cfun->ib_boundaries_block.
Ok. I don't see that we're going to get anything cleaner for 4.1.
r~
On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote:
> - Have flags work as now: -malign-double makes both 8,
> -mno-align-double
> makes both 4. Problem with that is the default is neither of these,
> and
> this doesn't fit neatly into gcc's model of two-valued flags; it's
> a
On Thu, Jul 21, 2005 at 05:21:58PM -0700, Dale Johannesen wrote:
> >Nah, you just remove it from target_flags, and control the two
> >new variables from ix86_handle_option.
>
> OK. Think that's the better approach?
*shrug* It's not horrible, I guess. It preseves existing
semantics when people
On Fri, Jul 22, 2005 at 11:30:40AM -0700, Chris Lattner wrote:
> Understood. I'm just looking for the minimum type alignment without
> user alignment. It appears that this is impossible to get from the
> targets, due to the way the targets can override type alignments in
> (almost completel
On Fri, Jul 22, 2005 at 02:13:12PM -0700, Chris Lattner wrote:
> Anyone have any thoughts or opinions? This may have impact on a
> number of things, including any pointer alignment analysis.
MEM_ALIGN has code to deal with this. There's no reason you can't
apply that to TYPE_ALIGN.
I suspect
On Sat, Jul 23, 2005 at 07:30:08AM -0700, Steve Kargl wrote:
> > I have that in my tree (gcc version 4.1.0 20050722 (experimental)), but
> > don't experience that failure.
> >
> > See my comments on PR 22623.
>
> Your comments are not relevant.
Well I don't see the failure either.
r~
On Sat, Jul 23, 2005 at 10:17:25AM -0700, Steve Kargl wrote:
> Note, you need to start with either an empty object tree
> and do a complete bootstrap or remove the libgfortran directory
> and do a bubblestrap.
I always start from zero.
I can see a failure from pinski's reduced test case. Fixed
b
On Tue, Jul 26, 2005 at 11:10:56PM -0700, Dale Johannesen wrote:
> Yes, it is. The following fixes my problem, and causes a couple of
> 3DNow-specific regressions
> in the testsuite which I need to look at, but nothing serious; I think
> it's gotten far enough to post
> for opinions. This is in
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> On Thu, 2005-07-28 at 12:48, David Daney wrote:
> > Also you can see that neither hello-world.o nor my libc-2.3.3.so have
> > any undefined symbols that would be satisfied by libgcc_s.so.
>
> It looks like you forgot to check the c
On Tue, Aug 02, 2005 at 08:32:53AM -0400, Diego Novillo wrote:
> Having said that, I sent rth a 4.0 patch for a similar bug that
> will "fix" this problem. Richard, have you applied it yet?
No, I forgot about it.
r~
On Tue, Aug 02, 2005 at 01:45:01PM -0700, Ian Lance Taylor wrote:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > > Yes, this is a compiler bug in the expansion of memcpy, please file a
> > > bug report. The solution is for the compiler to notice the memory
> > > alignment of the destinatio
On Wed, Aug 03, 2005 at 05:28:43PM +0200, Gunther Nikl wrote:
> Thank you. With "emit_insn (gen_rtx_USE (VOIDmode, reg))" the abort
> disappears. The same approach seems to fix the loads in the prologue.
> I hope that this is the correct solution.
No, it isn't. Your problem is that you havn
On Wed, Aug 03, 2005 at 12:15:05PM -0600, Shaun Jackman wrote:
> I'm not sure I understood the last line. s is a structure, and its
> address is aligned. How would you pass it to memcpy, and why would it
> generate an unaligned copy?
In the example I was replying to, S is a pointer to a structure,
On Wed, Aug 03, 2005 at 08:48:46PM -0400, Jack Howarth wrote:
> Also, this is based on IBM's ProPolice code, right?
Logically. It's a complete rewrite.
r~
On Wed, Aug 03, 2005 at 09:39:13PM -0400, Jack Howarth wrote:
> Do you think I should be able to build gcc itself with the
> -fstack-protector flag and what is the most appropriate way to
> achieve that (ie brute force using a CFLAG or some configure
> flag)?
Considering that I don't think tha
On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
> IIRC the C standard does not guarantee that an object stay within
> the bounds of its enumerated type. You'll have to do some digging
> in the relevant standards.
For the record, I believe we've addressed these issues sometime
withi
On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
> TYPE_MIN_VALUE (gnu_scalar_type)
> = gnat_to_gnu (Type_Low_Bound (gnat_entity));
> TYPE_MAX_VALUE (gnu_scalar_type)
> = gnat_to_gnu (Type_High_Bound (gnat_entity));
>
> This is wrong (as discussed before) and
On Tue, Aug 09, 2005 at 11:02:22AM -0700, H. J. Lu wrote:
> I have a small testcase to show that enable FTZ/DAZ makes a huge (>160
> times faster) difference on SSE floating point code. Icc enables it by
> defailt for -ON (N>=1). Should gcc do the same?
This is the flush-denormals-to-zero bit?
Se
On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> There is a minor problem. How can I add crtfastmath.o for SSE targets
> only?
You don't. You either add code to detect sse, or you make the
spec depend on -mfpmath=sse.
> Can I add a new macro, TARGET_EXPAND_MAIN_FUNCTION, to
> expand_
On Wed, Aug 10, 2005 at 08:48:44AM -0700, H. J. Lu wrote:
> * config.gcc (i[34567]86-*-linux*): Add i386/t-crtfm to tm-file.
> (x86_64-*-linux*): Likewise.
>
> * config/i386/crtfastmath.c: New file.
> * config/i386/t-crtfm: Likewise.
>
> * config/i386/linux.h (ENDFIL
On Thu, Aug 11, 2005 at 08:12:57AM +0800, Ling-hua Tseng wrote:
> I used the automata based pipeline description for my ports,
> I described the data latency time by `define_insn_reservation',
> and I'm trying to insert the "nop" in the hook
> TARGET_MACHINE_DEPENDENT_REORG.
It is possible to emi
On Fri, Aug 12, 2005 at 10:35:33PM +0200, Jan Hubicka wrote:
> Unforutnately the actual size we want to limit is somewhat variable (for
> kernel it is pretty small, in usual case few hounderd K is probably good
> choice).
I disagree. If recusion is involved, even a few K may be unacceptable.
That
On Sun, Aug 14, 2005 at 09:15:49AM +0800, Ling-hua Tseng wrote:
> I figured out the `free_bb_for_insn()' is called before the reorg pass,
> and I would like to use the CFG in the reorg pass for a reason.
You can't, because the reorg pass destroys the CFG. You'd have to
recompute the CFG from scra
On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote:
> But for general IPA working on the cgraph + GIMPLE level, as is what is
> happening here, I think we really need to do something about static
> variable initializers so they are in GIMPLE.
No. How could that possibly be? We can't e
On Sat, Aug 20, 2005 at 10:33:21PM -0400, Daniel Berlin wrote:
> > No. How could that possibly be?
> > We can't execute code for static
> > variable initializers, so how can we gimplify?
> What do you mean by this, exactly?
If you turn a static initializer into a code sequence, then it isn't a
s
On Sun, Aug 21, 2005 at 11:32:34PM -0400, Daniel Berlin wrote:
> See PR 23171.
Ok.
> If analyze_expr (or something) actually did that, i'd be a very happy
> man.
> It doesn't, unfortunately.
> Another perfectly reasonable solution would be to force us to not
> generate such crap in the first plac
On Mon, Aug 22, 2005 at 03:37:27PM +0200, Paolo Bonzini wrote:
> It may still make sense changing the default case of
> simplify_replace_rtx to invoke replace_rtx rather than returning x. But
> this is unrelated, because nobody is currently passing a SET to
> simplify_replace_rtx (only expressi
On Tue, Aug 23, 2005 at 09:28:50AM -0600, Roger Sayle wrote:
> Good catch. This is indeed a -ffast-math (or more precisely a
> flag_unsafe_math_optimizations) transformation. I'd prefer to
> keep these transformations with -ffast-math, as Jan described them
> as significantly helping SPEC's mesa
On Tue, Aug 23, 2005 at 11:40:16AM -0700, Dan Nicolaescu wrote:
> Is there a performance difference between the movl + movl and pushl
> code sequences?
In this case, no.
> If not maybe then gcc should generate pushl for -O2
> too because it is smaller code.
It's not quite as simple as you make o
101 - 200 of 812 matches
Mail list logo
