(See also thread on unexpected gcc errors)
This is on
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) sun4u:
binutils-2.15.92.0.2-5.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparcv9
> FAIL: gcc.misc-tests/bprob-1.c execution,-g -fprofile-arcs
> UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g
> -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution,
> -g -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution,-O0
> -fprofile-arcs
> UN
On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > FAIL: gcc.misc-tests/bprob-1.c execution,-g -fprofile-arcs
> > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g
> > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution,
> > -g -fbranch-probabilities FAIL: gcc.misc
Hello,
there seems to be a problem with the management of new ports.
- Documentation is inappropriate. There is a picky checklist to follow, but
it does not cover the interesting things, that is the list of de-facto
technical standards that we expect new ports to follow (with respect to
incomplet
Kurt Wall wrote:
On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:
On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
Also, a web-browser is much slower than an info-browser, especially
when doing searchs.
You must be close to the only user i've met who us
Gabriel Dos Reis wrote:
On Fri, 8 Jul 2005, Gerald Pfeifer wrote:
| On Fri, 8 Jul 2005, Gabriel Dos Reis wrote:
| > Is it true that nobody wanted to approved GCC-3.3.6 release
| > announcement? :-/
FWIW, I don't recall getting the request-for-approval message. But,
it's also possible that I
Original Message
> From: Daniel Berlin <[EMAIL PROTECTED]>
> Sent: Monday, July 11, 2005 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Some notes on the Wiki
>
> On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> > > I believe the Wiki is an invaluable documentation
Original Message
>From: Joe Buck
>Sent: 11 July 2005 20:07
> On Mon, Jul 11, 2005 at 08:07:20PM +0200, Sylvester Diehl wrote:
>> why doesn't gcc (-Wall -Wuninitalized -O) detect
>> an uninialized variable passed by reference
>> decleared as const * ?
>
> There are no uninitialized variab
"Dave Korn" <[EMAIL PROTECTED]> writes:
>>From: Joe Buck
>>
>> there are no uninitialized variables, as the address of k is
>> perfectly well defined.
>
> Indeed so, but I think Sylvester's point is that given that foo
> takes a const pointer, the compiler could theoretically know that
> foo ca
Original Message
>From: [EMAIL PROTECTED]
>Sent: 12 July 2005 10:56
> "Dave Korn" writes:
>
>> Myself, I was surprised that the inliner didn't catch on to what
>> was going on and complain. I would have expected that, but it
>> didn't even at O3.
>
> It does for me with mainline.
(See also thread on unexpected gcc, g++, and libstdc++ check-abi errors)
This is on
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) sun4u:
binutils-2.15.92.0.2-5.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc
If no one is suggesting an alternative, tested on x86 and x86_64-linux
where it restores bootstrap (at last :), ok to commit?
We're down to 6 ACATS FAIL on x86_64 and 8 on x86:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00654.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00653.html
On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Joe Buck reports the same problems on SPARC/Solaris:
> > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html
> >
> > According to my testing, the fix is to upgrade to GNU Bi
On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:
> On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> > On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> > > Joe Buck reports the same problems on SPARC/Solaris:
> > > http://gcc.gnu.org/ml/gcc-testresults/2005-07
Hello,
> If no one is suggesting an alternative, tested on x86 and x86_64-linux
> where it restores bootstrap (at last :), ok to commit?
I think the patch is fine (although of course I cannot approve it). The
more proper fix would be to never expand such expressions from ivopts;
I have a patch f
Hello,
On Tue, 12 Jul 2005, Jonathan Wakely wrote:
On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:
On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Joe Buck reports the same problems on SPARC/Solaris:
http:
On Tue, Jul 12, 2005 at 01:23:23PM +0200, Karel Gardas wrote:
>
> Hello,
>
> On Tue, 12 Jul 2005, Jonathan Wakely wrote:
>
> >On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:
> >
> >>On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> >>>On 7/12/05, Eric Botcazou <[EM
On Tue, 12 Jul 2005, Jonathan Wakely wrote:
On Tue, 12 Jul 2005, Jonathan Wakely wrote:
On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote:
On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Joe Buck reports the
On Tue, Jul 12, 2005 at 01:55:11PM +0200, Karel Gardas wrote:
> On Tue, 12 Jul 2005, Jonathan Wakely wrote:
>
> >>On Tue, 12 Jul 2005, Jonathan Wakely wrote:
> >>
> >>>The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
> >>>about the rest of GCC.
> >>
> >>does this also apply t
I think the patch is fine (although of course I cannot approve it).
I, as it's author, do not. But, as I keep saying, I don't know what
the proper fix is.
The more proper fix would be to never expand such expressions from ivopts;
What are "such expressions"?
Hello,
> I think the patch is fine (although of course I cannot approve it).
>
> I, as it's author, do not. But, as I keep saying, I don't know what
> the proper fix is.
preventing record_block_change from working in this situation seems a
quite clean solution to me; of course, not expand
config.guess reports: armv4l-unknown-linux-gnu
gcc -v reports:
Using built-in specs.
Target: armv4l-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --with-cpu=strongarm
--with-pic --prefix=/home/random/gcc4 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Bootstrapped on x86.
Hi,
I've been looking at the gcc.c-torture tests, it seems some of them rely
on undefined behaviour. For example, 920612-1.c looks like this:
f(j)int j;{return++j>0;}
main(){if(f((~0U)>>1))abort();exit(0);}
AIUI, this passes the largest possible positive integer to f(), which then
incre
I have been trying to cleanup the location where the persistent ipa
information is stored.
The original way that I did this was that I had a field in the var_ann
structure that pointed to the ipa_information.
Now that danny has reorganized the decls, the plan was to just add a
field to the f
Can a pointer appear in a C/C++ relational expression which doesn't test the
equality (or the inequality) of that pointer with respect to another pointer?
For example, are the comparisons in the following program legal code?
/* test.c */
#include
int main(int argc, char* argv[])
{
void
> I think that even if the use of relational operators other than '==' and '!='
> is legal with pointers, the compiler should issue a warning (when the option
> -Wall is used), as it does for assignment, used as truth values, not
> surrounded with parentheses.
Why?
It's legal, it's useful, and
On Tue, Jul 12, 2005 at 09:41:22AM -0500, Nicholas Nethercote wrote:
> I've been looking at the gcc.c-torture tests, it seems some of them rely
> on undefined behaviour. For example, 920612-1.c looks like this:
>
> f(j)int j;{return++j>0;}
> main(){if(f((~0U)>>1))abort();exit(0);}
Wow. It
On Tue, 12 Jul 2005, Nicholas Nethercote wrote:
> Similarly, the left-shifting in ROR causes signed integer overflow (I think)
> and so ROR relies on undefined behaviour. 20020508-3.c is similar.
To quote implement-c.texi:
GCC does not use the latitude given in C99 only to treat certain
asp
Original Message
>From: Daniel Berlin
>Sent: 12 July 2005 17:33
>> I think that even if the use of relational operators other than '==' and
>> '!=' is legal with pointers, the compiler should issue a warning (when
>> the option -Wall is used), as it does for assignment, used as truth
>> va
Mirco Lorenzoni wrote:
>Can a pointer appear in a C/C++ relational expression which doesn't test the
>equality (or the inequality) of that pointer with respect to another pointer?
>For example, are the comparisons in the following program legal code?
>
>/* test.c */
>#include
>
>int main(int ar
Jonathan Wakely wrote:
The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know
about the rest of GCC.
...
and IMHO testresults look quite good except abi_check, don't they? i.e. do
you mean updating binutils will resolve abi_check issue in libstdc++
testsuite?
I'd assume yes, b
Development environment:
i686-pc-mingw32 on Windows 2000 Pro SP4 (Athlon processor)
MinGW 3.2.0 (gcc 3.4.2 mingw-special)
Msys 1.0.10
../gcc-4.0.1/configure --verbose --with-gcc --with-gnu-ld
--with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingwlocal
--enable-threads --disable-nls -
In looking at the function inliner, I did some analysis of the
correctness of estimate_num_insns (from tree-inline.c), as this
measurement is critical to the inlining heuristics. Here is the
overview of what I found on the functions in two sample files from
the FAAD2 AAC library (measured
The page http://gcc.gnu.org/releases.html should be updated.
- Entries of recent releases GCC 4.0.0 and GCC 4.0.1 are missing.
In addition the headline of the table should be changed to:
"Please refer to our development plan for releases past 4.0.1 and future
releases."
Sincerely,
F. Fritsche
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> Such tests are in general bugs. You'd have to ask Torbjorn about what the
> original purpose of the old parts of c-torture was, as that may have
> differed from the current GCC testsuite, but invalid tests should be
> removed (or, perhaps better,
On Tue, Jul 12, 2005 at 11:39:18AM -0700, Ian Lance Taylor wrote:
> I would guess that 920612-1.c, at least, could just be changed to use
> unsigned int, and it would continue to test whatever bug it was
> testing when it was originally added.
>
The problem is somewhat more widespread now with th
Diego Novillo <[EMAIL PROTECTED]> writes:
> The problem is somewhat more widespread now with the tree
> optimizers. In particular with old test cases. Some of these
> cases are essentially optimized into empty functions by the time
> we get into the RTL passes.
Hmmm, yeah.
> We would have to a
I built 4.0.0 last week and thought I would update to 4.0.1. While
building 401 I got the following error:
--
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototyp
Chris Garrett wrote:
I built 4.0.0 last week and thought I would update to 4.0.1. While
building 401 I got the following error:
--
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-protot
On Tuesday 12 July 2005 19:56, Josh Conner wrote:
> In looking at the function inliner, I did some analysis of the
> correctness of estimate_num_insns (from tree-inline.c), as this
> measurement is critical to the inlining heuristics.
You don't say what compiler you used for these measurements. I
On Jul 11, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> In fact, a lot of projects don't even bother to distribute anything but
> HTML docs anymore (regardless of how they browse it).
And that's a pity, because it's a bit of a pain to turn the output of
grep -r regexp docs/HTML into something
If I am running Windows XP or some regular 32-bit Linux distribution,
can I still use gcc 3.4.x to compile a 64-bit A64 version of my code?
I have a program that uses 64-bit integers heavily, and I would like it
to utilize 64-bit mode in A64, even if this A64 is running a 32-bit OS.
Is this p
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Since pointer subtraction is well defined, and it returns an int, then ...
>
> int *a, *b;
>
> if (a < b)
> dosomething ();
>
> ... is just the same as ...
>
> int *a, *b;
>
> if ((b - a) >= 0)
> dosomething ();
This may not work correctly i
> Ada fails in stage1; the offender is gnatbind.exe. It crashes even if invoked
with no command-line arguments. > Gdb provides the following information:
>
>
> ( gdb) run
> Starting program: C:\gcc401install\gccbuild\gcc\stage1/gnatbind.exe
>Program received signal SIGSEGV,
> Segmentation fault.
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~
On 12 Jul 2005, at 21:58, David Rasmussen wrote:
If I am running Windows XP or some regular 32-bit Linux
distribution, can I still use gcc 3.4.x to compile a 64-bit A64
version of my code?
I have a program that uses 64-bit integers heavily, and I would
like it to utilize 64-bit mode in A
On Tue, Jul 12, 2005 at 05:54:00PM +0100, Dave Korn wrote:
> Original Message
> >From: Daniel Berlin
> >Sent: 12 July 2005 17:33
>
> >> I think that even if the use of relational operators other than '==' and
> >> '!=' is legal with pointers, the compiler should issue a warning (when
> >>
On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
> Pointer subtraction is only well defined if both pointers point to elements
> in the same array (or one past the end of the array). Otherwise the
> behaviour is undefined.
While this is correct, there are certain cases that the stan
On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
> > Pointer subtraction is only well defined if both pointers point to elements
> > in the same array (or one past the end of the array). Otherwise the
> > behaviour is undefi
Erik Trulsson <[EMAIL PROTECTED]> writes:
> On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
>> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
>> > Pointer subtraction is only well defined if both pointers point to elements
>> > in the same array (or one past the end of th
On Wed, Jul 13, 2005 at 12:28:47AM +0200, Erik Trulsson wrote:
> On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
> > On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
> > > Pointer subtraction is only well defined if both pointers point to
> > > elements
> > > in the same ar
On Sat, Jul 09, 2005 at 10:23:14PM +0200, Florian Michel wrote:
>
> Hello,
>
> I have a question concerning successfully assembling and linking the
> following assembly program on a linux AMD 64 machine:
>
> #cpuid2.s View the CPUID Vendor ID string using C library calls
> .section .datatext
>
On Mon, Jul 11, 2005 at 09:58:36AM -0500, Nicholas Nethercote wrote:
> Hi,
>
> There was recently a very long thread about the overflow behaviour of
> signed integers in C. Apparently this is undefined according to the C
> standard. I searched the standard on this matter, and while I did find
On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote:
> Erik Trulsson <[EMAIL PROTECTED]> writes:
> > I believe most C compilers support it in practice, but few, if any, have
> > actually documented it as a supported extension to C.
>
> I don't think we should, either. People who want to
On Tue, Jul 12, 2005 at 06:25:45PM +0200, Mirco Lorenzoni wrote:
> Can a pointer appear in a C/C++ relational expression which doesn't test the
> equality (or the inequality) of that pointer with respect to another pointer?
> For example, are the comparisons in the following program legal code?
>
On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote:
> Erik Trulsson <[EMAIL PROTECTED]> writes:
>
> > On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
> >> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote:
> >> > Pointer subtraction is only well defined if both poi
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote:
>> Erik Trulsson <[EMAIL PROTECTED]> writes:
>> > I believe most C compilers support it in practice, but few, if any, have
>> > actually documented it as a supported extension to C.
>>
>> I don't
Snapshot gcc-3.4-20050712 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050712/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050712
You'll
On Wed, Jul 13, 2005 at 01:28:14AM +0200, Falk Hueffner wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> > If you want to be pedantic, that's not portable; in particular, it
> > will break for some of the memory models used with 16-bit Windows
>
> You're missing my point; size_t was just an example
On Jul 12, 2005, at 1:07 PM, Steven Bosscher wrote:
You don't say what compiler you used for these measurements. I
suppose
you used mainline?
Yes, I am working with the mainline.
I think you should look at a lot more code than this.
OK - I stopped because I was seeing fairly consistent
First of all, I think you should handle ARRAY_RANGE_REF and ARRAY_REF
the same.
I don't think so. The latter is a memory reference while the former
is more like a NOP_EXPR: it's basically just creating a new array, which
can then either be indexed or pointed to.
On Tue, 12 Jul 2005, Joseph S. Myers wrote:
My question is: what exactly is gcc.c-torture testing? It seems to be
That GNU C code compiles or executes as expected for GNU C.
Is there a definition for GNU C? implement-c.texi and extend.texi have
some information about this, are there any
Kenneth Zadeck wrote:
The kludge to handle them is documented in cp/name-lookup.c around line
670
Ugh.
IMO, the right thing here is that there should be only one FUNCTION_DECL
for a given function, ever, period. Default arguments are not part of
"the function" in C++; they are an aspect of
Robert van Engelen wrote:
>
> 1. After reading the paper, we concluded that the scalar evolutions are
> actually a restricted polynomial form of chains of recurrences by
> Bachmann and Zima [6,8]. Is this true? Or is there an essential
> difference with multi-variate chains of recurrences [7]?
65 matches
Mail list logo
