--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-13
07:43 ---
Fixed on trunk.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
--- Comment #7 from dannysmith at gcc dot gnu dot org 2009-01-13 07:41
---
Subject: Bug 38580
Author: dannysmith
Date: Tue Jan 13 07:40:51 2009
New Revision: 143330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143330
Log:
PR bootstrap/38580
* gcc.c (process_co
--- Comment #6 from rob1weld at aol dot com 2009-01-13 07:16 ---
(In reply to comment #5)
> # Even if the default multilib is not a cross compilation,
> # it may be that some of the other multilibs are.
> if test $cross_compiling = no && test $multilib = yes \
>&& test "x${with_multi
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-01-13 06:07
---
Reply to comments 16 and 17 which I did not see before my commit. Please make
sure the original r143102 is in place when you apply latest patch. It does
seem bothersome that the xplor-nih is so sensitive. It i
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:57
---
Thanks for help Jack. The patch committed does fix the test case you provided.
Please double check with xplor-nih and if fixed as expected we can close this
PR.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:53
---
Subject: Bug 38772
Author: jvdelisle
Date: Tue Jan 13 05:53:07 2009
New Revision: 143328
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143328
Log:
2009-01-12 Jerry DeLisle
PR libfortran/3877
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:40
---
Subject: Bug 38772
Author: jvdelisle
Date: Tue Jan 13 05:40:36 2009
New Revision: 143327
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143327
Log:
2009-01-12 Jerry DeLisle
PR libfortran/3877
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-01-13
05:31 ---
I'll do a fresh bootstrap with the proposed patch tomorrow. We may have a
separate regression that appeared since I last checked the full xplor-nih
testsuite. Basically, the following difference is appeari
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-01-13
05:06 ---
Jerry,
While that eliminated the failure in the xtarget.inp testcase for
xplor-nih, it also increased the number of test case failures from 13 to 72 out
of 133 tests. I'll test Daniel's patch to see if
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 05:02 ---
There is no java source compiler in 4.3 and above so the number of tests have
decreased.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I built gcc version 4.4.0 20090104 (experimental) (GCC) and configured with:
../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++
--enable-shared --disable-static --enable-decimal-float --with-long-double-128
--enable-nls --with-included-gettext --enable-gather-detailed-me
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:36
---
Here is a patch. If the character is not a digit or a blank, we exit the loop
and skip the test for not a digit. DUH! (first part of patch is just an
indentation fix)
Index: read.c
===
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:14
---
The problem is in read.c. In reading floats we are not catching invalid
exponent characters. The BN patch just revealed this bug that has been there
all along.
The string can be just about anything with an 'e'
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-01-13 03:44
---
Great work Jack. Now we have a test case to work with.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
+++ This bug was initially created as a clone of Bug #14435 +++
I built "gcc version 4.4.0 20090111 [trunk revision 143259]" and when I
run "make -i check" it sets 'GCC_EXEC_PREFIX="/usr/local/lib/gcc/"'.
It seems gcc may look for this directory:
# ls -lrtA /usr/local/lib/gcc/i386-pc-solaris2.1
--- Comment #5 from rob1weld at aol dot com 2009-01-13 02:52 ---
(In reply to comment #4)
> >"Cannot build gnattools while gnatlib is out of date or unbuilt".
> That bug is a different issue than this bug. Please don't confuse the two.
I searched before I posted to try to avoid a dupe.
--- Comment #19 from bkoz at gcc dot gnu dot org 2009-01-13 01:49 ---
Subject: Bug 38384
Author: bkoz
Date: Tue Jan 13 01:49:30 2009
New Revision: 143322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143322
Log:
2009-01-12 Benjamin Kosnik
PR libstdc++/38384
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-01-13 01:35 ---
on trunk (4.4.x):
1) ld --version
GNU ld (GNU Binutils) 2.19
checking for ld version... 21900
2) ld --version
GNU ld version 2.18.50.0.9-7.fc10 20080822
checking for ld version... 21850
3) ld --version
GNU ld (GNU B
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-13 01:23 ---
Subject: Bug 35109
Author: jason
Date: Tue Jan 13 01:23:34 2009
New Revision: 143320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143320
Log:
PR c++/35109
* name-lookup.c (lookup_name_real):
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 01:09 ---
We should be able to fold:
VIEW_CONVERT_EXPR(D.919509.D.78313.D.78008)
Into just D.919509 .
The indirect issue is a different one which needs to be fixed anyways as it
causes aliasing issues which were not in the o
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 01:03 ---
Confirmed, though your patch is not portable really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 01:01 ---
for ac_var in `(set) 2>&1 |
sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 00:59 ---
How did you invoke configure? How did you invoke GNU make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-01-13
00:55 ---
The attached badread,f test program produces...
F
...when attempting to read a float with...
READ(TEMP,'(F20.0)',ERR=) R
from
TEMP='END'
when run against the libg
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:54 ---
I have no idea why this happens for you but it works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38728
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-01-13
00:52 ---
Created an attachment (id=17081)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17081&action=view)
test program demonstrating missing error condition
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 ---
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs are.
if test $cross_compiling = no && test $multilib = yes \
&& test "x${with_multisubdir}" != x ; then
cr
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 ---
Hmm, automake should have done the correct thing ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:42 ---
a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is needed
for libgcc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||bug-classpath at gnu dot org
Severity|major
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 00:38 ---
Coverage builds should not be bootstrapped.
Profiled bootstrap means build stage1 with no opts and then stage2 with
generating the profiling data and then build some target libraries (not all
though) and the build s
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 ---
*** Bug 38800 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 ---
fixincludes is already registered as PR 25470.
And really PR 3415 is the original bug for it.
*** This bug has been marked as a duplicate of 3415 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:32 ---
You should not be bootstrapping a --enable-coverage=noopt build, you should
only need to build stage1 gcc.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-13 00:31 ---
Nobody builds using --enable-intermodule, it uses too much memory in general
anyways so closing as won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:28 ---
Well you don't understand any of these options it seems.
First --enable-coverage=nopt does nothing except changes the CFLAGS really.
There is nothing in the toplevel makefile or configure which uses
--enable-coverag
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 ---
*** Bug 38746 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 ---
*** This bug has been marked as a duplicate of 33443 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|i386-pc-solaris2.11 |
GCC h
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:18 ---
>"Cannot build gnattools while gnatlib is out of date or unbuilt".
That bug is a different issue than this bug. Please don't confuse the two.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323
--- Comment #3 from rob1weld at aol dot com 2009-01-13 00:14 ---
In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have
the: "Cannot build gnattools while gnatlib is out of date or unbuilt" Bug.
# gmake clean-gcc
...
# gmake
...
gmake[4]: Leaving directory
`/usr/s
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 23:59 ---
Thanks for your help Dave: this should be fixed now. (FWIW, the 10.20 config is
correct, or mostly correct.) Still, it's nice to confirm.
Ranier, this should be working now. Can you try to cross-compile as before, bu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38810
--- Comment #2 from rob1weld at aol dot com 2009-01-12 23:35 ---
(In reply to comment #0)
> With --enable-languages=c,fortran, system trys to build gnattools and fails
> with this error:
> ...
> Cannot build gnattools while gnatlib is out of date or unbuilt
> ...
That may occur if you u
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-12 23:00 ---
The 4.3 version seems to be the old one, with is_* prefixes and macro, while
trunk/4.2 are the new ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-12 22:50 ---
Fixed in trunk, gcc-4_3 and gcc-4_2.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dodji at gcc dot gnu dot org 2009-01-12 22:48 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:47:49 2009
New Revision: 143315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143315
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #6 from dodji at gcc dot gnu dot org 2009-01-12 22:44 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:44:13 2009
New Revision: 143314
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143314
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #5 from dodji at gcc dot gnu dot org 2009-01-12 22:41 ---
Subject: Bug 36019
Author: dodji
Date: Mon Jan 12 22:41:19 2009
New Revision: 143313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143313
Log:
gcc/cp/ChangeLog:
2009-01-12 Dodji Seketeli
PR c++/36
--- Comment #2 from jlerouge at apple dot com 2009-01-12 22:22 ---
Verified fixed with 4.3.3.
--
jlerouge at apple dot com changed:
What|Removed |Added
Status
--- Comment #2 from john dot spelis at 3dlabs dot com 2009-01-12 22:16
---
Subject: Re: C++ bitfield static initialisation problem
Thank you.
(I'm suitably humbled).
Cheers
On 12 Jan 2009, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #1 from pinskia at gcc dot gnu
--- Comment #6 from vmakarov at redhat dot com 2009-01-12 22:12 ---
Yes, it is an IRA bug. Code processing calls to functions can throw is
lost in IRA.
I'll submit a patch tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-12 21:56
---
*** Bug 38817 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:56 ---
This was fixed for 4.3.3 by the patch for PR 36548.
*** This bug has been marked as a duplicate of 36548 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-12 21:38 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:37 ---
*(unsigned long *)this=l;
You are violating C/C++ aliasing rules which invokes undefined behavior as you
are accessing a giChannelTiming as a unsigned long.
Either use -fno-strict-aliasing or memcpy or unions or th
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-12 21:37 ---
Subject: Bug 38515
Author: spop
Date: Mon Jan 12 21:36:58 2009
New Revision: 143311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143311
Log:
2009-01-12 Sebastian Pop
PR tree-optimization/38515
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 21:36 ---
fixed for 4.4.x/4.3.x
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #17 from bkoz at gcc dot gnu dot org 2009-01-12 21:32 ---
Subject: Bug 36801
Author: bkoz
Date: Mon Jan 12 21:32:19 2009
New Revision: 143310
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143310
Log:
2009-01-12 Benjamin Kosnik
Jonathan Larmour
--- Comment #13 from jason at gcc dot gnu dot org 2009-01-12 21:07 ---
Subject: Bug 31488
Author: jason
Date: Mon Jan 12 21:07:46 2009
New Revision: 143308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143308
Log:
PR c++/31488
* tree.c (pod_type_p): Return 1 for
--- Comment #16 from bkoz at gcc dot gnu dot org 2009-01-12 20:57 ---
Created an attachment (id=17080)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17080&action=view)
for gcc-4_3-branch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
The following test wrongly fails with a floating point exception (division
by integer 0) when built with -O2 for i686-pc-linux-gnu. Based on an
example posted by Robert Seacord to the WG14 reflector. It works with 3.4 and
earlier, fails with 4.0 and later. The % operation may trap if it is % 0
(
The following program seems to show a
compiler bug on x86 using 4.3.2 compilers
The correct output should be;
giChannelTiming0.Setup 0xff
giChannelTiming0.Recover 0xff00
which occurs only when no optimiser or -O is used.
When -O2 or greater is used the mask's are incorrectly
computed an
--- Comment #5 from aesok at gcc dot gnu dot org 2009-01-12 20:42 ---
Subject: Bug 29141
Author: aesok
Date: Mon Jan 12 20:41:57 2009
New Revision: 143306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143306
Log:
PR target/29141
* config/avr/t-avr (LIB1ASMFUNCS)
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-12 20:28 ---
Well for -m32/-m64 case, it might be difference in 32bit vs 64bit conversions
:).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38808
--- Comment #14 from markus dot schoepflin at comsoft dot de 2009-01-12
20:01 ---
Just to recap what I think the problem is:
1) cc1 compiles the C file and creates input for the system assembler. The
assembler source is placed into the /tmp directory.
2) The system assembler is called
--- Comment #13 from markus dot schoepflin at comsoft dot de 2009-01-12
19:51 ---
Strange, I seem to get something different on Linux with gcc 4.3.2:
~/src/tests/gcc/PR4605$ gcc -v -c hello.c -o "./dir test/hello.o"
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/c
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-12 19:45 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 19:44 ---
Subject: Bug 32041
Author: jakub
Date: Mon Jan 12 19:44:33 2009
New Revision: 143305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143305
Log:
PR c/32041
* c-parser.c (c_parser_postfix_express
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-12 19:29 ---
(In reply to comment #3)
> That is what I am saying. There should be an exclusion for that one file only.
Why? this is what should be done and how this has been implemented for a long
time.
-fprofile-arcs does n
+++ This bug was initially created as a clone of Bug #38465 +++
For 4.4, "info -f /usr/local/info/gccint.info -n Passes" needs to document
the 'Graphite Pass' in the "Passes" section. At minimum a link to a Doc.
--
Summary: [4.4 Regression] graphite undocumented
Product: g
The following code seems to be wrongly optimized by GCC:
int main(int argc, char **argv) {
unsigned int foo = 3;
return ((838237499u * foo - 2137600414u) % 11u);
}
always return 0 on my machine, it should return 7. GCC seems to be optimizing
the modulo operation (even with -O0).
GCC versio
--- Comment #18 from amylaar at gcc dot gnu dot org 2009-01-12 18:09
---
(In reply to comment #17)
> I think enabling partial PRE to do it is appropriate (with at most inserting
> on one edge).
I think the abstraction with tree-ssa and cfglayout mode has gone too far.
We no longer have
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-12
18:03 ---
The following code:
__thread long tl = 42;
long f(void)
{
long *l = &tl;
register long r0 __asm__ ("r0");
register long *r1 __asm__ ("r1");
r0 = 23;
r1 = l;
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-12
18:01 ---
Subject: Re: [4.4 Regression] Incorrect delayed branch optimization
> I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
> hppa because of bugs in DBR. I never filed a bug becau
--
Summary: Taking the address of a __thread variable prevents the
r0 register from being loaded
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-12 17:39 ---
things really have a random flavor right now. I have a bt for a segfault from
gdb, within a couple of minutes now:
[ repeats about 4000 times]
#4011 0x0049267d in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fort
--- Comment #24 from aph at gcc dot gnu dot org 2009-01-12 17:36 ---
Subject: Bug 38396
Author: aph
Date: Mon Jan 12 17:35:48 2009
New Revision: 143301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143301
Log:
2009-01-12 Andrew Haley
PR libgcj/38396:
* libgc
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-12 17:27 ---
Is this an IRA bug?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:59 ---
For the diagnostics: I think it works, but we are checking in case of
C_LOC(Type%Comp) the symbol Type instead of Comp. Assume that Type is a
pointer and Comp is not then "gfc_is_data_pointer()" returns true for Type
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:39 ---
For quick reading, skip next part and continue below the * * *.
---
I think this applies still (at least partially) as libgfortran/config/fpu*.h's
set_cpu() still has the line. For GLIBC one finds:
/* gli
version used for testing:
GNU Fortran (GCC) version 4.4.0 20090112 (experimental) [trunk revision 143288]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090112 (experimental) [trunk revision
143288], GMP version 4.2.2, MPFR version 2.3.1.
valgrind --tool=memcheck
/data03
--- Comment #20 from pault at gcc dot gnu dot org 2009-01-12 16:20 ---
Created an attachment (id=17079)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17079&action=view)
A preliminary patch for the PR
A slightly earlier version of this regtested OK. Will do it to this version
toni
--- Comment #21 from jakub at gcc dot gnu dot org 2009-01-12 16:18 ---
Created an attachment (id=17078)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17078&action=view)
gcc44-pr38245.patch
Patch I'm playing with. I don't see why changing CALL_INSN_FUNCTION_USAGE
to have only at m
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 15:45 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-12 15:43 ---
Subject: Bug 38794
Author: jakub
Date: Mon Jan 12 15:43:22 2009
New Revision: 143292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143292
Log:
PR c++/38794
* decl.c (start_function): If grokde
--- Comment #6 from tomby at gcc dot gnu dot org 2009-01-12 15:37 ---
Subject: Bug 38385
Author: tomby
Date: Mon Jan 12 15:37:09 2009
New Revision: 143291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143291
Log:
PR middlend/38385
* tree-loop-distribution.c (pro
--- Comment #8 from rguenther at suse dot de 2009-01-12 15:16 ---
Subject: Re: [4.4 regression] warnings from -isystem
headers strikes back.
On Mon, 12 Jan 2009, pluto at agmk dot net wrote:
>
>
> --- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 ---
> (In reply t
--- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 ---
(In reply to comment #5)
> I can't seem to compile the preprocessed source:
i've attached a new full archive.
$ make
rm -f *.ii *.o *.s
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2
-g0 -fP
--- Comment #4 from ubizjak at gmail dot com 2009-01-12 15:06 ---
-fno-ira fixes the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
--- Comment #8 from carlos at systemhalted dot org 2009-01-12 15:02 ---
Dave,
I've been building parts of glibc's vfprintf code with -fno-delayed-branch for
hppa because of bugs in DBR. I never filed a bug because it was almost
impossible for me to reduce the vfprintf code (large file,
--- Comment #6 from pluto at agmk dot net 2009-01-12 15:01 ---
Created an attachment (id=17077)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17077&action=view)
full testcase (src + .ii + mkefile)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
--- Comment #12 from ubizjak at gmail dot com 2009-01-12 14:59 ---
Hm, on i686-pc-linux-gnu -v gives:
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic'
/usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -quiet -v dir
test/hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-12 14:51
---
Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the
declaration are not from system-headers (this is then the default for -Wall)
and with -Wstrict-aliasing=2 (or =1) warn if either of the
--- Comment #13 from pluto at agmk dot net 2009-01-12 14:43 ---
(In reply to comment #12)
> This isn't really a warning from system headers:
>
> test.cpp:14: warning: dereferencing pointer '__x.13' does break
> strict-aliasing
> rules
>
> the location for the dereference is in test.cp
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-12 14:30 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-12 14:25
---
This isn't really a warning from system headers:
test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing
rules
the location for the dereference is in test.cpp (if that is correct or not
is
--- Comment #2 from joel at gcc dot gnu dot org 2009-01-12 14:23 ---
It is not appearing here:
(powerpc-aix) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01087.html or
(powerpc-darwin) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01077.html
so it is fixed. Sorry for missed com
--- Comment #1 from joel at gcc dot gnu dot org 2009-01-12 14:20 ---
Is this still happening? I accidentally did not commit the change to
lib/target-supports.exp and did it over the weekend (Saturday?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
--- Comment #11 from markus dot schoepflin at comsoft dot de 2009-01-12
14:17 ---
Here is the result of using -### instead of -v:
scho...@area51:~/local/src/tests/gcc/4605> /opt/gcc-4.3.2/bin/gcc -### -c
hello.c -o 'dir test/hello.o'Using built-in specs.
Target: alphaev56-dec-osf5.1b
C
1 - 100 of 126 matches
Mail list logo
