Paul Schlie wrote:
Just as:
volatile int* port = (int*)PORT_ADDRESS;
int input = *port; supposedly invoking an undefined behavior.
is required to be well specified, effectively reading through a pointer
an un-initialized object's value, and then assigning that unspecified value
to the variab
I've been trying to track down an build failure that I was pretty sure
came about from some patches I've been trying to merge, but I've now
reduced things to a bare unmodified tree and it's still failing. I
could have sworn that it wasn't doing that until I started adding
things, though, so I'
El Mon, Jan 29, 2007 at 02:28:34PM -0500, Daniel Berlin ens deleit� amb les
seg�ents paraules:
> On 1/29/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote:
>> Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33:
>>
>>> Hi,
>>>
>>> Does gcc apply inter-procedural optimizations across functions call
On 1/30/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
I've been trying to track down an build failure that I was pretty sure
came about from some patches I've been trying to merge, but I've now
reduced things to a bare unmodified tree and it's still failing. I
could have sworn that it wasn't doing
On 1/29/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
-fdump-tree-all-all will work
as will -fdump-rtl-all-all
I never added support for -fdump-all-all-all :)
Thank you!
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampto
On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> I've been looking into the gcc sources and I'm somewhat confused.
> Are gcc/g++ comepletely independent programs or do they share a backend?
In the source code, they share a
On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote:
> GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The
> canonical location is:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128
>
> As with all prereleases, the issue of most concern to me is packaging.
> Therefor
Hi,
On Tuesday 30 January 2007 04:06:36 Mark Mitchell wrote:
> GCC 4.1.2 RC1 is now on ftp://gcc.gnu.org and its mirrors. The
> canonical location is:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070128
>
> As with all prereleases, the issue of most concern to me is packaging.
> Therefore,
I can no longer build libjava on a machine with "just" 512MB of main
memory (FreeBSD/i386 5.4 in this case).
Three weeks ago the build worked on that very machine; did we raise
our minimum requirements or is this simply a bug?
Gerald
echo
/sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swin
On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote:
> If you do encounter problems, please file a Bugzilla PR, and add me to
> the CC: list for the issue. Please do not send me reports without first
> filing a PR, as I am unable to keep track of all the issues if they are
> not in the d
Gerald Pfeifer writes:
> I can no longer build libjava on a machine with "just" 512MB of main
> memory (FreeBSD/i386 5.4 in this case).
>
> Three weeks ago the build worked on that very machine; did we raise
> our minimum requirements
We just imported a whole new release of the Classpath li
Hi all,
I am getting this when I try to compile gcc trunk:
../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
-fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings
-Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attrib
> Robert wrote:
>> Paul Schlie wrote:
>> - agreed, and thereby objects having no legitimate trap representation,
>> such as most if not all implementations of integers and floating point
>> objects on most if not all current target machines, and thereby their
>> access does not invoke an undefined
Andrew Haley wrote:
Gerald Pfeifer writes:
> I can no longer build libjava on a machine with "just" 512MB of main
> memory (FreeBSD/i386 5.4 in this case).
>
> Three weeks ago the build worked on that very machine; did we raise
> our minimum requirements
We just imported a whole new rele
> Paul wrote
>> Robert wrote:
>>> Paul Schlie wrote:
>>> - agreed, and thereby objects having no legitimate trap representation,
>>> such as most if not all implementations of integers and floating point
>>> objects on most if not all current target machines, and thereby their
>>> access does not i
> Paul Jarc wrote:
>> Paul Schlie wrote:
>> is required to be well specified [...] as otherwise the language
>> couldn't be utilized to write even the most hardware drivers
>> required of all computer systems.
>
> In a sense, the language *can't* be used to write most hardware
> drivers. Drivers d
Hi all,
There are two platforms on which mainline is broken:
* bootstrap is broken for i386-netbsd, see PR30058
* the compiler built on i386-mingw32 is unusable, see PR30589
Both regressions were introduced by Geoffrey Keating
(http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a "C99
Marco Trudel writes:
> Andrew Haley wrote:
> > Gerald Pfeifer writes:
> > > I can no longer build libjava on a machine with "just" 512MB of main
> > > memory (FreeBSD/i386 5.4 in this case).
> > >
> > > Three weeks ago the build worked on that very machine; did we raise
> > > our mini
On 29 Jan 2007 11:38:15 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
I don't see why you would have to modify any code in the frontend.
You would modify the middle-end code. Rebuilding the compiler would
rebuild cc1, cc1plus, etc.
Well, I spent the morning looking at the code and since
On Tue, 2007-01-30 at 07:02 -0500, Paul Schlie wrote:
> > There is no license to reason about how you think code is
> generated, any
> > compiled is allowed to generate code AS IF a trap representation
> were present.
>
> - yes, and thereby inconsistent with reality, and thereby wrong.
> (as ma
Paul Schlie wrote:
- as trap representation within the context of C is a value
representation which is not defined to be a member of a type, where if
accessed or produced evokes undefined behavior; so admit as to the best of
my knowledge all potentially enclosable values for IEEE floats and doub
Paul Schlie wrote:
- yes, and thereby inconsistent with reality, and thereby wrong.
(as may and may not are equivalent possibilities)
The standard is the only reality here. If you cannot deduce semantic
behavior from the semantic model of the standard, then you cannot
deduce it. You are not a
On Sun, Jan 28, 2007 at 12:43:36AM +0100, Richard Guenther wrote:
> >Can you explain what went through your mind when you picked the
> >tree_exp.complexity field for something implemented new... :-(
>
> Not much...
>
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html
>
> "... but my brai
Paul Schlie wrote:
The root of this discussion was based on whether or not GCC's relatively
aggressive assumption that an undefined behavior gave it the reasonable
and useful right to presume that any expression which may be interpreted
as having undefined semantics may be presumed to either mys
On Tue, Jan 30, 2007 at 08:36:47AM +0100, Paolo Bonzini wrote:
> * cp/cp-tree.h (OMP_ATOMIC_CODE): Delete.
> (OMP_ATOMIC_DEPENDENT_P): Rewrite.
> * cp/pt.c (tsubst_expr): Adjust for new format of dependent OMP_ATOMIC
> expressions.
> * cp/semantics.c (finish_omp_atomic
On Tue, Jan 30, 2007 at 10:49:02AM -0500, Robert Dewar wrote:
> Paul Schlie wrote:
>
> >- as trap representation within the context of C is a value
> >representation which is not defined to be a member of a type, where if
> >accessed or produced evokes undefined behavior; so admit as to the best o
Ismail Dönmez <[EMAIL PROTECTED]> writes:
> I am getting this when I try to compile gcc trunk:
>
> ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
> -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings
> -Wstrict-prototypes
> -Wmissing-prototypes
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
> There are two platforms on which mainline is broken:
> * bootstrap is broken for i386-netbsd, see PR30058
> * the compiler built on i386-mingw32 is unusable, see PR30589
>
> Both regressions were introduced by Geoffrey Keating
> (http://
> libcpp/files.c:1238 seems to be a call to memcpy. I don't see
> anyplace a floating point exception might come from. I've certainly
> never seen anything like that.
Division by zero somewhere?
--
Eric Botcazou
On Tuesday 30 January 2007 11:44, Robert Schwebel wrote:
> On Mon, Jan 29, 2007 at 07:06:36PM -0800, Mark Mitchell wrote:
> > If you do encounter problems, please file a Bugzilla PR, and add me to
> > the CC: list for the issue. Please do not send me reports without first
> > filing a PR, as I am
Hello,
I've grepped through the remaining uses of Unwind_Word in libgcc and
the related word_mode uses in gcc and would like to discuss how to go
on with these.
One target is to identify more places where we can get rid of _Unwind_Word.
Other places exist where we definitely need a data type lik
On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote:
> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
>
> Therefore, please do not make any checkins to the 4.1 branch after 2PM
> PST. Once RC1 is uploaded, the branch will be open only for changes
> which have m
On 30/01/2007, at 8:48 AM, Ian Lance Taylor wrote:
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
There are two platforms on which mainline is broken:
* bootstrap is broken for i386-netbsd, see PR30058
* the compiler built on i386-mingw32 is unusable, see PR30589
Both regressions
As it turns out, I do now have access to a NetBSD system, and will
look at that problem when I next get time.
Thanks. When you provid a patch, I will test it. (If someone else ever
wants access to a netbsd system, it's worth noting there's one on the
GCC compile farm!)
My understanding from 30
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > I am getting this when I try to compile gcc trunk:
> >
> > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
> > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -W
> make STAGE1_CFLAGS="-O"
> BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE"
> profiledbootstrap
Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
--
Eric Botcazou
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote:
> > make STAGE1_CFLAGS="-O"
> > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer
> > -U_FORTIFY_SOURCE" profiledbootstrap
>
> Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
Ok btw bootstrapping compiler is,
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote:
> > make STAGE1_CFLAGS="-O"
> > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer
> > -U_FORTIFY_SOURCE" profiledbootstrap
>
> Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
And I am still getting floating p
Ismail Dönmez wrote:
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote:
make STAGE1_CFLAGS="-O"
BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer
-U_FORTIFY_SOURCE" profiledbootstrap
Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
And I am still getting
> And I am still getting floating point exception even with a bare make. Any
> way to debug this?
Not easily unless you already know the innards of the compiler, I'm afraid.
--
Eric Botcazou
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> Anyway, I tried again, this time with the right file, and it took
Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll
An
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Gerald Pfeifer <[EMAIL PROTECTED]> writes:
>
> | On Sun, 28 Jan 2007, Joe Buck wrote:
> | > It's probably time to turn off 4.0 snapshots; the last ones will
> | > probably be Gaby's prerelease snapshots, and the release should come
> | > soon.
> |
>
Rask Ingemann Lambertsen wrote:
> On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote:
>> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
>>
>> Therefore, please do not make any checkins to the 4.1 branch after 2PM
>> PST. Once RC1 is uploaded, the branch will be
On Tue, 30 Jan 2007, Mark Mitchell wrote:
> >PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a
> > regression from 4.1.1. A patch was posted earlier this month at
> > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have
> > regrettably forgotten to ping this patch
Robert Schwebel wrote:
> What about PR28516, would it be acceptable for 4.1.2?
There are two issues:
(1) it's not marked as a 4.1 regression, let alone a regression from
4.1.x. Did this test case work with older versions of GCC?
(2) Richard Earnshaw objected to applying the patch to 4.1 becaus
On Wednesday 31 January 2007 01:26, Mark Mitchell wrote:
> Robert Schwebel wrote:
> > What about PR28516, would it be acceptable for 4.1.2?
>
> There are two issues:
>
> (1) it's not marked as a 4.1 regression, let alone a regression from
> 4.1.x. Did this test case work with older versions of GCC
On Tue, 30 Jan 2007, Andrew Haley wrote:
> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
>
> and indeed, it does want a lot of memory - at peak some 550m. It'll
> be smaller on a 32-bit box, but not much smaller.
Ouch. I can confirm that on a 32-bit box of mine it
Gabriel Paubert wrote:
For all architectures I use, it is rather "if used as an operand
of an arithmetic instruction", but the values can be copied
around without ever generating a trap. Even negating or taking
the absolute value never traps since those are not considered
"arithmetic" instruc
Joseph S. Myers wrote:
> On Tue, 30 Jan 2007, Mark Mitchell wrote:
>
>>>PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a
>>> regression from 4.1.1. A patch was posted earlier this month at
>>> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have
>>> regrettably fo
Paul Brook wrote:
> On Wednesday 31 January 2007 01:26, Mark Mitchell wrote:
>> Robert Schwebel wrote:
>>> What about PR28516, would it be acceptable for 4.1.2?
>> There are two issues:
>>
>> (1) it's not marked as a 4.1 regression, let alone a regression from
>> 4.1.x. Did this test case work wit
Richard,
Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
on a bunch of java testcases under mipsel-linux.
It looks related to (but not necessarily caused by) this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
For example if we examine the assembler ou
David Daney <[EMAIL PROTECTED]> writes:
> Sometime between 1/7 and 1/16 on the trunk I started getting wrong code
> on a bunch of java testcases under mipsel-linux.
>
> It looks related to (but not necessarily caused by) this patch:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01346.html
>
> F
52 matches
Mail list logo
