headers
Eric Botcazou | 1 Oct 2005 01:00
Picon

Re: GCC 4.0.2 Released

> I've decided not to do another release.  I think it's too much effort
> for too little gain.  The C++ and m68k patches are things that might
> just as easily not have been applied in the first place; we certainly
> wouldn't have considered either PR a showstopper.  The Solaris problem
> is unfortunate, but I think not fatal.

Agreed.  But I'm requesting a "caveat" note about the Solaris regression here:
  http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
mentioning the workaround (g++ -pthreads) and the link:
  http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html

--

-- 
Eric Botcazou
Permalink | Reply | 3 comments |
headers
Richard Kenner | 1 Oct 2005 01:09
Picon

Confusion with tree_ssa_useless_type_conversion_1

At one point, that function used to pretty much just call
lang_hooks.types_compatible_p.  Now it does more.  Specifically, it can
return TRUE even if the lang hook returns FALSE.  That's a problem for
the optimizers and causes performance regressions.

For example, I noticed that trivial trail recursion elimination isn't
being done for Ada.  I used the simple example:

function Fact (I: Integer) return Integer is
begin
   if I = 1 then
      return 1;
   else
      return I * Fact (I - 1);
   end if;
end Fact;

The problem is the operand "I - 1".  The type "Integer" is really a subtype
(of Integer'Base).  So "I" is of that type. "I - 1", being an operand, is of
type Integer'Base.  So the call above actually has a conversion from the base
type to the subtype.  However, those two types look the same to
tree_ssa_useless_type_conversion_1 even though the langhook uses the default
and says they aren't.  That means that gimplification omits the conversion
which, in turn, means that the actual and formal aren't the same type
if you just use the lang hook. Tail recursion declines to optimize
it because of that.  The following fixes it:

*** tree-tailcall.c	28 Jul 2005 16:29:56 -0000	2.47
--- tree-tailcall.c	30 Sep 2005 18:39:38 -0000
*************** find_tail_calls (basic_block bb, struct
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Hubicka | 1 Oct 2005 01:17
Picon

Re: x86 SSE constants

> The C constraint on x86 is defined, in both the doc and the comments, as
> "constant that can be easily constructed in SSE register without loading
> from memory".   Currently the only one handled is 0, but there is at 
> least
> one more, all 1 bits, which is constructed by
>    pcmpeqd  %xmm, %xmm
>  Unfortunately there are quite a few places in the patterns that assume 
> C
> means zero, and generate pxor or something like that.  What would be
> the preferred way to fix this, new constraint or change the existing 
> patterns?
My original plan was to add pcmpeqd by extending the 'C' constraint and
the patterns where pxor/xorp? is currently generated unconditionally.
This is pretty similar to what we do to i387 constants as well.  I never
actually got to realizing this (for the scalar FP work I was mostly
interested in that time it was not at all that interesting), but I think
there is nothing in md file preventing it (or I just missed it when it
was added :)...

Honza
Permalink | Reply | 3 comments |
headers
Dale Johannesen | 1 Oct 2005 01:31
Picon
Favicon

Re: x86 SSE constants


On Sep 30, 2005, at 4:17 PM, Jan Hubicka wrote:

>> The C constraint on x86 is defined, in both the doc and the comments, 
>> as
>> "constant that can be easily constructed in SSE register without 
>> loading
>> from memory".   Currently the only one handled is 0, but there is at
>> least
>> one more, all 1 bits, which is constructed by
>>    pcmpeqd  %xmm, %xmm
>>  Unfortunately there are quite a few places in the patterns that 
>> assume
>> C
>> means zero, and generate pxor or something like that.  What would be
>> the preferred way to fix this, new constraint or change the existing
>> patterns?
> My original plan was to add pcmpeqd by extending the 'C' constraint and
> the patterns where pxor/xorp? is currently generated unconditionally.
> This is pretty similar to what we do to i387 constants as well.  I 
> never
> actually got to realizing this (for the scalar FP work I was mostly
> interested in that time it was not at all that interesting), but I 
> think
> there is nothing in md file preventing it (or I just missed it when it
> was added :)...

No, there isn't, but it might be a smaller change to add a new 
constraint....
having constraints tied to specific constants is pretty ugly, and so is
(Continue reading)

Permalink | Reply | 2 comments |
headers
George White | 1 Oct 2005 01:02

incompatible 'improvements'

Hello,

I would like to suggest that in the future you pay more attention
to backwards computability.  There have been at least 4 instances
where you broke the compiler with regard to being able to compile
legacy code.  I have > 500K lines of older code which works perfectly
well and should not be impacted by what I regard as cosmetic changes
to the allowed syntax.  The main reason I choose to use gcc was that
I didn't have to worry about different compilers doing different
things and allowing or disallowing different syntax options.  

Many of these incompatibilities have had to do with the treatment of
static subroutines.  The latest break down (whose inability to be
backwards compatible is apparently due to unit-at-a-time-mode) is not
allowing static declarations of functions within the module where the
function is used.  I have no objection to making things like this
result in new warnings, as long as I can turn the warning off if I
want, but making them result in errors is absolutely wrong.  This is
the third time you have done this with static functions, each time
making the most expedient path to a solution stop working.  Another
instance had to do with disallowing extra text in # directives.

Frankly, I don't care what standards say is no longer acceptable
syntax.  If I have something that works, I expect it to continue to
work.  What's next?  Are you going to start imposing your source code
formatting standards?  Stop emulating Microsoft, who has little regard
for maintaining backwards computability and start emulating Sun who is
generally very good at this.

Regards,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Mitchell | 1 Oct 2005 01:46

Re: GCC 4.0.2 Released

Eric Botcazou wrote:
>>I've decided not to do another release.  I think it's too much effort
>>for too little gain.  The C++ and m68k patches are things that might
>>just as easily not have been applied in the first place; we certainly
>>wouldn't have considered either PR a showstopper.  The Solaris problem
>>is unfortunate, but I think not fatal.
> 
> 
> Agreed.  But I'm requesting a "caveat" note about the Solaris regression here:
>   http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
> mentioning the workaround (g++ -pthreads) and the link:
>   http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html

Roger that.  I'll take care of it as soon as I can.

Thanks,

--

-- 
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
(916) 791-8304
Permalink | Reply | 0 comments |
headers
Robert Dewar | 1 Oct 2005 02:02
Favicon

Re: incompatible 'improvements'

George White wrote:

> Frankly, I don't care what standards say is no longer acceptable
> syntax. 

Well it is a goal of gcc to be compatible with the standard. Really
it should be a goal of yours to make sure your code is correct, i.e.
that it conforms with the standard, and if you write incorrect code,
you cannot expect it to be accepted by the compiler in the first
place. It is certainly not the case that you can assume that because
the compiler accepts your code, that it is correct.

> If I have something that works, I expect it to continue to
> work. 

THat's a wrong expectation. If you write incorrect code, you cannot
expect it to keep working.

If you have a requirement for old incorrect legacy code to keep
working, that's reasonable, but you are going to need to find
someone (and presumably pay them) to maintain the old incorrect
legacy compilers that go along with your old incorrect legacy code.

Sure, it would be good if the compiler never accepted the bad code
in the first place, but if a bug is found, it has to be fixed.

> What's next?  Are you going to start imposing your source code
> formatting standards?

Non sequitur, since this has nothing to do with language standards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Oct 2005 02:11
Picon
Favicon

Re: Aliasing violation generated by fold_builtin_memcmp?

On Fri, Sep 30, 2005 at 01:49:59PM -0400, Andrew Pinski wrote:
> Something like this will fix the issue with TYPE_REF_CAN_ALIAS_ALL
> by removing the use.  Maybe we could move may_alias to a bit in the
> types and move TYPE_REF_CAN_ALIAS_ALL from the pointer type to the
> type which is being accessed instead of this mess.

Close.  

> +	build_type_attribute_variant (ttype,
> +				      merge_attributes
> +				        (TYPE_ATTRIBUTES (to_type), 
> +					 tree_cons (get_identifier ("may_alias"),
> +						    NULL_TREE, NULL_TREE)));

If ALIAS_SET had been computed on ttype, this will leave it set.
You'd need to force set it to zero here.  You can also avoid 
creating a new type for C for the case in question by checking 
that the original type has alias set zero.

>        return build_pointer_type_for_mode (build_type_no_quals (TREE_TYPE (t)),
>  					  TYPE_MODE (t),
> -					  TYPE_REF_CAN_ALIAS_ALL (t));
> +					  false);

You'd also want to delete all traces of TYPE_REF_CAN_ALIAS_ALL.

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Oct 2005 02:11
Picon
Favicon

Re: Aliasing violation generated by fold_builtin_memcmp?

On Fri, Sep 30, 2005 at 11:20:53AM -0400, Richard Kenner wrote:
> That's easy enough for integer types, but creating multiple record types
> means duplicating lots of fields and layouts and is, in general, a mess.

Yeah, so?  How often do you think this feature is used, anyway?

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Oct 2005 02:24
Picon
Favicon

Re: x86 SSE constants

On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote:
> No, there isn't, but it might be a smaller change to add a new 
> constraint....
> having constraints tied to specific constants is pretty ugly, and so is
> having (if (constant value==0)) in a lot of patterns..,,

That's why you'd centralize this into a few functions.  There
are several things that need changing:

  * Match different forms of constant for C.

  * Update vector_move_operand to use that same routine.

  * A routine to determine which of several instructions
    we want to emit.  E.g. xorps instead of pxor for -Os.
    It should return a ATTR_MODE result so that we can 
    call it from the mode attribute of various instructions.

  * A routine that uses the previous to return a const char*
    template to return from the insn output patterns.

For bonus points, handle MMX too.

r~
Permalink | Reply | 1 comment |

Gmane