On Fri, Sep 30, 2005 at 04:02:07PM -0700, George White wrote:
> 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.
The C standard t
Yeah, so? How often do you think this feature is used, anyway?
Quite a lot in legacy Ada code.
But how often it's used doesn't matter: if it's used *at all*, we still
have to create the mechanism for duplicating record types.
On Sep 30, 2005, at 8:46 PM, Neil Booth wrote:
nmake Technical Support wrote:-
This is to request reinstatement of the -I- command line directory
search option. Sorry for the late request, we only recently became
aware that -I- is deprecated in gcc 4.0.
I agree this should not be removed (
nmake Technical Support wrote:-
> This is to request reinstatement of the -I- command line directory
> search option. Sorry for the late request, we only recently became
> aware that -I- is deprecated in gcc 4.0.
I agree this should not be removed (have been removed?). It is now
provided by a l
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
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~
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 access
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
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 Solari
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
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, wh
> 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, %
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 recu
> 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 unfort
> Steve Kargl writes:
Steve> If you review the emails in fortran@ for the few months, you'll find
Steve> that the copyright clerk has acknowledged receiving a disclaimer from
Steve> Asher. This clerk probably discarded it because it was not a FSF
approved
Steve> assignment. In addition, sev
Hi,
Recently I've been getting strange errors on ill-formed code. It looks
as if the compiler is not stopping after an error, but running the
assembler anyway:
dp-matrix.H:110: error: extra qualification 'DPmatrix::' on member
'DPmatrix' ignored
dp-matrix.H:132: error: extra qualificatio
On Fri, Sep 30, 2005 at 05:10:01PM -0400, David Edelsohn wrote:
> > Steven Bosscher writes:
>
> Steven> On Friday 30 September 2005 21:36, Asher Langton wrote:
> >> On Thu, 29 Sep 2005, Jack Howarth wrote:
> >> > Asher,
> >> >Any progress on the paperwork?
> >>
> >> None. I haven't recei
Kean Johnston wrote:
>> I'd appreciate feedback. (I don't promise to be bound by the majority
>> view, though.)
>
> I seem to recall in the past that they did patch releases.
> From both a tagging purity point of view and reproducability
> point ov view, why not create a branch off 4.0.2, apply t
> Steven Bosscher writes:
Steven> On Friday 30 September 2005 21:36, Asher Langton wrote:
>> On Thu, 29 Sep 2005, Jack Howarth wrote:
>> > Asher,
>> >Any progress on the paperwork?
>>
>> None. I haven't received anything from the FSF. I just pinged them
>> again. The FSF does have a di
On Fri, Sep 30, 2005 at 11:01:53PM +0200, Steven Bosscher wrote:
> On Friday 30 September 2005 21:36, Asher Langton wrote:
> > On Thu, 29 Sep 2005, Jack Howarth wrote:
> > > Asher,
> > >Any progress on the paperwork?
> >
> > None. I haven't received anything from the FSF. I just pinged them
>
On Friday 30 September 2005 21:36, Asher Langton wrote:
> On Thu, 29 Sep 2005, Jack Howarth wrote:
> > Asher,
> >Any progress on the paperwork?
>
> None. I haven't received anything from the FSF. I just pinged them
> again. The FSF does have a disclaimer from LLNL, which seems like it
> shou
Rainer tracing seems to show that strange thing happen to
Osint.Running_Program during elaboration of 4.0.x. We have:
package body Osint is
Running_Program : Program_Type := Unspecified;
...
procedure Set_Program (P : Program_Type) is
begin
...
Running_Program := P;
end Set_Prog
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
Unfor
On Fri, Sep 30, 2005 at 11:23:23AM +0200, Olivier Hainque wrote:
> We are seeing regressions in our local testsuite on cases exercising
> that pragma.
Hmm.
> The 'tag alias set should be zero if ...' idea above seems logical to me.
> I still may well not yet see a number of other options.
Pe
I'd appreciate feedback. (I don't promise to be bound by the majority
view, though.)
I seem to recall in the past that they did patch releases.
From both a tagging purity point of view and reproducability
point ov view, why not create a branch off 4.0.2, apply the
fixes that were missed, tag it
Matthias Klose wrote:
Mark Mitchell writes:
Daniel Jacobowitz wrote:
My inclination is to do nothing (other than correct the target
milestones on these bugs in bugzilla) and move on. The Solaris problem
is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
a crisis meriti
Mark Mitchell writes:
> Daniel Jacobowitz wrote:
>
> >>My inclination is to do nothing (other than correct the target
> >>milestones on these bugs in bugzilla) and move on. The Solaris problem
> >>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
> >>a crisis meriting anoth
On Fri, Sep 30, 2005 at 10:59:45AM -0700, H. J. Lu wrote:
> It doesn't have to a formal release. I would just make a snapshot from
> the 4.0 branch and point the affected people to it. If there isn't
> enough, you can always make another snapshot. You can update 4.0.2
> release web page and mention
On Fri, Sep 30, 2005 at 11:03:31AM -0700, Joe Buck wrote:
> On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> > Ulrich Weigand wrote:
> >
> > > Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks
> > > like the fix is in the release according to the current Chan
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote:
> Was this a regression from 4.0.0 or 4.0.1?
I doubt it.
> > Personally, I'd do a 4.0.3 based on current bits.
>
> The problem is that it's not just me banging on the release button
> (which does itself take quite a lot of time, sinc
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> Ulrich Weigand wrote:
>
> > Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks
> > like the fix is in the release according to the current ChangeLog, but
> > in fact it wasn't:
>
> Indeed, cvs log confirms that
On Fri, Sep 30, 2005 at 10:54:22AM -0700, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
> >>My inclination is to do nothing (other than correct the target
> >>milestones on these bugs in bugzilla) and move on. The Solaris problem
> >>is bad, and I beat up on Benjamin to get it fixed, but I'm
Mark Mitchell <[EMAIL PROTECTED]> writes:
> The key question is whether to do an immediate 4.0.3 to catch up to what
> we intended. (That's not entirely trivial, in that things have now been
> checked in on the 4.0 branch, so we would have to temporarily back out
> some patches, or apply tags ver
Daniel Jacobowitz wrote:
>>My inclination is to do nothing (other than correct the target
>>milestones on these bugs in bugzilla) and move on. The Solaris problem
>>is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
>>a crisis meriting another release cycle. The C++ change
On Sep 29, 2005, at 8:32 PM, Daniel Berlin wrote:
Any suggestions how to fix this?
The easiest thing is to store a version of unsigned_char_type_node
somewhere that has it's TYPE_ALIAS_SET set to 0, and use it there.
Whether this is the best solution, i'll leave to others :)
Something li
On Fri, Sep 30, 2005 at 10:06:07AM -0700, Mark Mitchell wrote:
> The key question is whether to do an immediate 4.0.3 to catch up to what
> we intended. (That's not entirely trivial, in that things have now been
> checked in on the 4.0 branch, so we would have to temporarily back out
> some patche
Because the RTL level only supports type based aliasing, and very simple
TBAA at that.
But we're just talking about type-based aliasing.
You are saying that an access through this pointer can point to
anything, regardless of what we think it points to.
No. If you know what i
On Fri, 2005-09-30 at 12:45 -0400, Richard Kenner wrote:
> > What's special here is the pointer type, not the underlying type.
>
> Which means that everywhere that handles pointer types and aliasing has
> to be modified to check this magic.
>
> At the RTL level, there's just one p
Ulrich Weigand wrote:
> Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks
> like the fix is in the release according to the current ChangeLog, but
> in fact it wasn't:
Indeed, cvs log confirms that the revision was made to cp/init.c on
September 22.
It appears that the rel
--- Ulrich Weigand wrote:
> Comparing the cp/ChangeLog files from 4.0.2 and the
> 4_0 branch, it looks
> like the fix is in the release according to the
> current ChangeLog, but
> in fact it wasn't:
Indeed,
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gc
But of course, it's the right thing to do when you've got one type that
can be aliased to anything through a pointer, and the other cannot.
Sure, if that's what were going on, but it's not.
What we have are two *pointer types*, both pointing at the same
underlying type. Access via one
Added a better subject line.. Pete.
[EMAIL PROTECTED] wrote on 09/30/2005 11:03:59 AM:
>
> I'm not entirely sure how gcc's CFG structure all fits together yet, so
> I'll ask for some input on this one:
>
> While looking through some dumps from a compile using -fprofile-use, I
> noticed the follo
I'm not entirely sure how gcc's CFG structure all fits together yet, so
I'll ask for some input on this one:
While looking through some dumps from a compile using -fprofile-use, I
noticed the following in the "jump" dump file:
Basic block 164 prev 163, next -2, loop_depth 0, count 1672, freq 148
On Fri, 2005-09-30 at 11:20 -0400, Richard Kenner wrote:
> Uh, CAN_ALIAS_ALL seems like a very bad hack then.
> You should simply be creating a pointed-to type that aliases set 0, and
> using that for the pointed to type.
> That is, after all, what alias set 0 is for.
>
> That's ea
Uh, CAN_ALIAS_ALL seems like a very bad hack then.
You should simply be creating a pointed-to type that aliases set 0, and
using that for the pointed to type.
That is, after all, what alias set 0 is for.
That's easy enough for integer types, but creating multiple record types
means
On Fri, 2005-09-30 at 16:53 +0200, Olivier Hainque wrote:
> Daniel Berlin wrote:
> > Well, doesn't the pointed-to type have set 0 because of
> > TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)?
>
> Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the
> pointed-to type:
>
>/* N
Daniel Berlin wrote:
> Well, doesn't the pointed-to type have set 0 because of
> TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)?
Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the
pointed-to type:
/* Nonzero in a pointer or reference type means the data pointed to
by t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 29, 2005 at 09:35:22AM -0700, Richard Henderson wrote:
> On Thu, Sep 29, 2005 at 07:32:46AM -0400, Richard Kenner wrote:
> > The real fix is below, though I haven't run it throuh a testing
> > cycle yet. I was wondering how this ever worke
On Fri, 2005-09-30 at 16:29 +0200, Olivier Hainque wrote:
> Daniel Berlin wrote:
> > > I am still unclear on one point: is it fine to reuse the same tag for
> > > possibly different designated types ?
> >
> > Yes, as long as they have the same alias set.
>
> OK. A last detail:
>
> On the fir
Daniel Berlin wrote:
> > I am still unclear on one point: is it fine to reuse the same tag for
> > possibly different designated types ?
>
> Yes, as long as they have the same alias set.
OK. A last detail:
On the first tag_set 0 creation, we get into:
if (var_ann (ptr)->type_mem_tag =
On Fri, 2005-09-30 at 15:54 +0200, Olivier Hainque wrote:
> Daniel Berlin wrote:
> > > Out of a preliminary look into this code (new to me), a possible
> > > place to address that appears to be 'get_tmt_for', which
> > > presumably should assign a zero alias set to tags for pointer
> > > types
Daniel Berlin wrote:
> > Out of a preliminary look into this code (new to me), a possible
> > place to address that appears to be 'get_tmt_for', which
> > presumably should assign a zero alias set to tags for pointer
> > types with that bit set.
> Actually, you just want it to assign the same
On Fri, 2005-09-30 at 11:23 +0200, Olivier Hainque wrote:
> Richard Henderson wrote:
> > Try
> >
> > cst_uchar_ptr_node
> > = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true);
> >
> > which is apparently in use by the Ada front end, but only if a
> > certain pragma is given. Du
On September 30, 2005 09:15, [EMAIL PROTECTED] wrote:
> ../../gcc/cp/name-lookup.h:315: conflicting types for `lookup_name'
> ../../gcc/c-common.h:783: previous declaration of `lookup_name'
>
There are two conflicting definitions for lookup_name between C and C++.
For now the best approach is t
Mark Mitchell wrote:
> No, that's very weird; that was PR 23993, which I fixed. Or, thought I
> did. It's definitely fixed for me on x86_64-unknown-linux-gnu. But,
> the nature of the bug didn't seem at all system-dependent. I've checked
> that I have no local patches in my GCC 4.0.x tree. So
Hi,
I just checked out gomp-20050608-branch from the CVS and tried to
compile it. This is the error I got:
gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-fno-common -DHAVE_CONFIG_H -I. -Icp -I../.././gcc
-I../.././gcc/cp
Hi H. J.
Is there any plan to support Windows/x86-64?
No and yes. I think that we would like to support this target, but we
just need contributers to work on it. (I am pretty sure that some
people are working on it, but they may not be ready to contribute yet).
What are needed for the p
Richard Henderson wrote:
> Try
>
> cst_uchar_ptr_node
> = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true);
>
> which is apparently in use by the Ada front end, but only if a
> certain pragma is given. Dunno how reliably that's likely to work.
We are seeing regressions in our
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>GCC 4.0.2 has been released.
>
>
> Results on s390(x)-ibm-linux are here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01324.html
>
> Unfortunately, it is not zero-FAIL after
59 matches
Mail list logo
