--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-22 06:47 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-22 06:42 ---
Subject: Bug 41429
Author: jakub
Date: Tue Sep 22 06:42:26 2009
New Revision: 151966
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151966
Log:
PR middle-end/41429
* tree-cfg.c (remove_useless_
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-22 03:08 ---
My Linux/ia32 machine may be dying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41432
--- Comment #42 from pogma at gcc dot gnu dot org 2009-09-22 02:28 ---
Subject: Bug 41260
Author: pogma
Date: Tue Sep 22 02:28:19 2009
New Revision: 151960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151960
Log:
PR middle-end/41260
* gcc/config.gcc: Use darwin9.h and darwin10
--- Comment #29 from davek at gcc dot gnu dot org 2009-09-22 01:34 ---
Subject: Bug 41357
Author: davek
Date: Tue Sep 22 01:33:53 2009
New Revision: 151959
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151959
Log:
PR middle-end/41357
* varasm.c (default_encode_s
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-22 01:17 ---
Subject: Bug 41404
Author: davek
Date: Tue Sep 22 01:17:24 2009
New Revision: 151958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151958
Log:
PR bootstrap/41404
* dwarf2out.c (mem_loc_descri
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-21 23:15 ---
Gcc is configured with
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
Linux/x86-64 seems OK. Use
--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in
On Linux/ia32, gcc becomes slower and slower. Here
are the bootstrap timings:
r151702: 12788.41user 452.16system 2:01:15elapsed 181%CPU
r151707: 13228.29user 458.77system 2:05:31elapsed 181%CPU
r151710: 13890.39user 478.57system 2:11:31elapsed 182%CPU
r151716: 14319.75user 494.71system 2:14:51elap
The following code snippet is wrongly rejected
int main() { sizeof(&main); }
---
main.cpp: In function 'int main()':
main.cpp:1: warning: ISO C++ forbids taking address of function '::main'
---
But the Standard allows that within a sizeof, because according to 3.2/2 it
does not constitute a "use
--- Comment #9 from longb at cray dot com 2009-09-21 21:31 ---
The OpenMP spec does require (requirement is on the user):
"chunk_size must be a loop invariant integer expression with a positive value",
so detection of a chunk size of -7 at run time would be a user-friendly thing
to do.
--- Comment #10 from rwild at gcc dot gnu dot org 2009-09-21 20:15 ---
Created an attachment (id=18629)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18629&action=view)
proposed patch
Please try out this patch. The problem is, libtool turns off language compiler
detection reliabl
--- Comment #25 from hjl dot tools at gmail dot com 2009-09-21 19:53
---
(In reply to comment #24)
> OK, so I have finally got to the root of the assert failure in
> reg-stack.c described in the bug description. The file is indeed
> miscompiled, and the miscompiled function is VEC_cha
--- Comment #24 from jamborm at gcc dot gnu dot org 2009-09-21 19:49
---
OK, so I have finally got to the root of the assert failure in
reg-stack.c described in the bug description. The file is indeed
miscompiled, and the miscompiled function is VEC_char_base_replace.
A very short one
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-21 18:59 ---
I think it is safe to ignore it, as you've done.
It is target specific which bits are masked away and how. It is enough that
for LO_SUM we look up the SYMBOL_REF referenced by the second operand.
--
http://gcc.gn
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-21 18:50 ---
OK. this is what I've done
(a) bootstrapped with Jakub's path but modified thus
>> Common Report Var(dwarf_strict) Init(1)
- bootstrap succeeds (with the four errors mentioned in #26).
(b) I then ha
--- Comment #4 from joel at gcc dot gnu dot org 2009-09-21 18:45 ---
The patch allowed my build of sparc-rtems4.10 C/C++ to complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
--- Comment #11 from jakub at gcc dot gnu dot org 2009-09-21 18:32 ---
The #c10 problem is that df marks pseudo 60 used last in j += i; (and then just
in 2 DEBUG_INSNs following it) as REG_DEAD in that instruction and drops the
DEBUG_INSN uses below it on the floor.
--
http://gcc.gn
--- Comment #20 from nightstrike at gmail dot com 2009-09-21 18:12 ---
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > > ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
> > > > warning: 'str' may be used uninitialized i
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-21 18:06 ---
Created an attachment (id=18628)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18628&action=view)
gcc45-pr41429.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #19 from kargl at gcc dot gnu dot org 2009-09-21 18:01 ---
(In reply to comment #18)
> (In reply to comment #17)
> > > ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
> > > warning: 'str' may be used uninitialized in this function
> >
> > I think t
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18627)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18627&action=view)
bad config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18626)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18626&action=view)
good config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2009-09-21 17:51
---
Subject: Re: Can't build libgomp without
--enable-languages=fortran
* davek at gcc dot gnu dot org wrote on Mon, Sep 21, 2009 at 07:44:49PM CEST:
> Created an attachment (id=18625)
--> (http://gcc.gnu.org/bug
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625&action=view)
bad rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18624)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18624&action=view)
good rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-21 17:36 ---
By using this code and compiling with gcc test.c -O2 I can reproduce this for
i686-pc-linux, x86_64-pc-linux, x86_64-pc-mingw32, and for i686-pc-mingw32.
--
ktietz at gcc dot gnu dot org changed:
What
--- Comment #18 from nightstrike at gmail dot com 2009-09-21 17:36 ---
(In reply to comment #17)
> > ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
> > warning: 'str' may be used uninitialized in this function
>
> I think this warning is bogus:
> index_
--- Comment #3 from ubizjak at gmail dot com 2009-09-21 17:34 ---
The testcase compiles OK with 4.3.5, 4.4.2 and 4.5.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #30 from jakub at gcc dot gnu dot org 2009-09-21 17:25 ---
Yes, we know for certain binutils are fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-09-21
17:07 ---
Do we even know for certain that older versions of bintuils really work
properly with the newer dwarf3/dwarf4? I wonder how much of the general
instability in the recent bootstraps might be related these t
--- Comment #17 from burnus at gcc dot gnu dot org 2009-09-21 17:01 ---
> ../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
> warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i
--- Comment #28 from developer at sandoe-acoustics dot co dot uk
2009-09-21 16:46 ---
(In reply to comment #27)
> I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
> likely -gstrict-dwarf wasn't used when compiling something that has been
> linked
> into th
--- Comment #9 from Woebbeking at web dot de 2009-09-21 16:46 ---
So it's ok to change the behavior in a minor release?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #4 from rwild at gcc dot gnu dot org 2009-09-21 16:44 ---
With PR 35619 fixed in trunk it works fine for me to build in the source tree.
Feel free to Cc: me on new bugs arising from an in-tree build.
(Leaving bug open as it addresses 4.4 not trunk.)
--
http://gcc.gnu.org
--- Comment #16 from nightstrike at gmail dot com 2009-09-21 16:33 ---
(In reply to comment #14)
> Subject: Bug 41219
>
> Author: jvdelisle
> Date: Sat Sep 12 15:08:27 2009
> New Revision: 151653
As of r151914, this warning still exists when the host=linux64 and the
target=win64.
--
--- Comment #15 from nightstrike at gmail dot com 2009-09-21 16:30 ---
Current list:
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1847:10: warning:
variable 'elem' might be clobbered by 'longjmp' or 'vfork'
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1849:10: warn
--- Comment #3 from jason at gcc dot gnu dot org 2009-09-21 16:30 ---
Fixed, thanks.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from janis at gcc dot gnu dot org 2009-09-21 16:22 ---
Subject: Bug 41049
Author: janis
Date: Mon Sep 21 16:22:43 2009
New Revision: 151934
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151934
Log:
PR c/41049
* real.c decimal_from_integer, decimal
--- Comment #2 from jason at gcc dot gnu dot org 2009-09-21 16:11 ---
Subject: Bug 41421
Author: jason
Date: Mon Sep 21 16:11:26 2009
New Revision: 151932
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151932
Log:
PR c++/41421
* tree.c (trivial_type_p): Fix logic
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-21 15:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #27 from jakub at gcc dot gnu dot org 2009-09-21 15:37 ---
I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
likely -gstrict-dwarf wasn't used when compiling something that has been linked
into those libraries.
No idea if Mach-O has any tools simi
Somewhere between mainline revisions 151661 and 151676 I started getting new
testsuite failures from objc++ as shown here:
Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01158.html
FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html
The new failures are:
FAIL: obj-c++.dg/e
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-09-21 15:04 ---
To reproduce, target x86_64-unknown-linux-gnu and compile g++.dg/gomp/pr37189.C
with:
cc1plus -quiet -v pr37189.C -dumpbase pr37189.C -mtune=generic -auxbase pr37189
-version -fopenmp -fpic -o pr37189.s
--
Somewhere between mainline revision 151676 and 151704 I started getting several
gomp failures which manifest as timeouts in the testsuite when using
-fpic/-fPIC.
Here are the differing testsuite results:
Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html
FAIL: http://gcc.gnu.org/ml
--- Comment #8 from paolo dot carlini at oracle dot com 2009-09-21 14:45
---
Agreed, unspecified, as the actual citation says.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #7 from schwab at linux-m68k dot org 2009-09-21 14:25 ---
(In reply to comment #3)
> As far as I can see, you are triggering undefined behavior.
There is a big difference between undefined and unspecified behaviour. With
unspecified behaviour the implementation must chose a
--- Comment #26 from developer at sandoe-acoustics dot co dot uk
2009-09-21 14:24 ---
(In reply to comment #23)
> Created an attachment (id=18621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit]
> gcc45-pr41405.patch
as pre previous comment - this bootstra
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-09-21 14:22 ---
*** Bug 41427 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-09-21 14:22 ---
*** This bug has been marked as a duplicate of 2288 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-21 14:06 ---
Mine. I'm going to disentangle the maze in substitute_and_fold by introducing
another hook in the generic SSA propagator to fold a stmt.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
extern "C" void abort (void);
inline void *operator new (__SIZE_TYPE__, void *__p) throw () { return __p; }
int __attribute__((noinline))
foo(void)
{
float f = 0;
int *i = new (&f) int (1);
return *(int *)&f;
}
CCP produces
:
f = 0.0;
D.2121_3 = &f;
D.2107_4 = (int *) &f;
if (D.210
Consider this code:
void f1()
{
for (int i = 0;;)
int i;
}
void f2()
{
for (int i = 0;;)
{
int i;
}
}
void f3()
{
for (int i = 0;;)
{
{
int i;
}
}
}
Only f3() should compile, yet f1() and f2() compile too.
While f1() seems
--- Comment #3 from mahatma at eu dot by 2009-09-21 13:12 ---
Created an attachment (id=18623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18623&action=view)
linux-2.6.31 deconfig x86_64 error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025
--- Comment #2 from mahatma at eu dot by 2009-09-21 13:08 ---
(In reply to comment #1)
> Can you provide the preprocessed source?
>
Yes. After make/error:
http://mahatma.bspu.unibel.by/download/transit/glibc-2.10.1-error.tar.bz2
(gentoo flavored, sorry)
New info: it happened on -O2 or
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-21 13:08 ---
Switch assembly is optimized if you handle all valid cases (which you do) into
if (i != 0)
case B
else
case A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #11 from ubizjak at gmail dot com 2009-09-21 13:02 ---
Another week, another patch in testing:
Index: c-typeck.c
===
--- c-typeck.c (revision 151915)
+++ c-typeck.c (working copy)
@@ -9465,6 +9465,7 @@ build_b
--- Comment #5 from Woebbeking at web dot de 2009-09-21 12:53 ---
Paolo, but std::cout << static_cast(i); prints 5, so it's not the
conversion but the switch statement which is "broken".
Richard, if it's only truncation shouldn't case B be triggered?
--
http://gcc.gnu.org/bugzilla/
I think g++ simplifies too early array types into pointers when looking for a
conversion sequence in a return statement.
---
struct B
{
B (int (&v)[10]);
B();
};
B g2()
{
int c[10];
return c;
}
---
results in
test.cc: In function B g2():
test.cc:10: error: conversion from int
--- Comment #25 from developer at sandoe-acoustics dot co dot uk
2009-09-21 12:45 ---
(In reply to comment #23)
> Created an attachment (id=18621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit]
> gcc45-pr41405.patch
thanks for the patch.
I bootstrapped
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-21 12:44 ---
In C++ an enum type only has the minimum number of bits that is required to
store all its values, thus 1 in your case. So (foo)5 is a truncation.
--
rguenth at gcc dot gnu dot org changed:
What|R
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-21 12:41
---
As far as I can see, you are triggering undefined behavior. Per 5.2.9/7: "A
value of integral or enumeration type can be explicitly converted to an
enumeration type. The value is unchanged if the original value
--
Woebbeking at web dot de changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #2 from Woebbeking at web dot de 2009-09-21 12:21 ---
g++ case.cpp is sufficient to reproduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #1 from Woebbeking at web dot de 2009-09-21 12:19 ---
Created an attachment (id=18622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18622&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #24 from dominiq at lps dot ens dot fr 2009-09-21 12:19 ---
> Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless
> explicitly set on the command line). I went through all the DWARF 3 and DWARF
> 4 additions used by dwarf2out.c, except DW_CFA_* so far.
If I cast an int to the enum type all values outside the enum triggers the
first case-statement.
The number of enum values is important. It must be a power of 2.
This works in GCC 4.3.4.
--
Summary: switch with enums doesn't work
Product: gcc
Version: 4.4.1
--- Comment #14 from t7 at gmail dot com 2009-09-21 11:05 ---
I can confirm this is fixed in gcc-4_4-branch.
Thank you.
--
t7 at gmail dot com changed:
What|Removed |Added
--- Comment #2 from xxcv07 at gmail dot com 2009-09-21 10:47 ---
Sorry about this invalid report, my mistake in building ffmpeg.
--
xxcv07 at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from xxcv07 at gmail dot com 2009-09-21 10:25 ---
Looks like I may have made a mistake in compiling a library which was causing
this issue, will report back later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--- Comment #23 from jakub at gcc dot gnu dot org 2009-09-21 10:22 ---
Created an attachment (id=18621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view)
gcc45-pr41405.patch
Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless
explicitly set on
--- Comment #6 from burnus at gcc dot gnu dot org 2009-09-21 10:04 ---
(In reply to comment #5)
> Please mark the bug as user error.
> Sorry for the false alert.
Great that it now works for you. (Closed as INVALID.)
--
burnus at gcc dot gnu dot org changed:
What|
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2009-09-21 09:04 ---
Dominique has confirmed what I've found, that some changes beyond
151814->151815 are also significant.
test results for powerpc-apple-darwin8 and i686-apple-darwin9
http://gcc.gnu.org/ml/gcc-testresul
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
--- Comment #4 from scott dot gccbugs dot 2009 at scottrix dot co dot uk
2009-09-21 08:46 ---
Thanks for the help, I have got the intermediate files out and can see what you
mean. I'll raise the issue with binutils. Again, thanks for the help and very
quick response.
--
http://gc
--- Comment #22 from jakub at gcc dot gnu dot org 2009-09-21 08:40 ---
Created an attachment (id=18620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18620&action=view)
gcc45-pr41404.patch
This fixes the bug, unfortunately doesn't do any good with CONST_STRINGs.
CONST_STRING as em
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-21 08:05 ---
Changed the subject to reflect the comments.
> [this might not be quite enough; backing out of only 151814->151815 for trunk
> version 151904 produced a working bootstrap but with still some dsymutil
> fails].
I do
--- Comment #5 from ian dot james at bnymellon dot com 2009-09-21 07:59
---
I separated the directories of Solaris packaged GNU (/usr/sfw), open built GNU
(/usr/local) and locally built GNU components (usr/gnu) components, putting the
built ones earlier in LD_LIBRARY_PATH and PATH. I th
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-21 07:53 ---
(In reply to comment #3)
> First off, do you happen to know whether this is a regression?
'fraid not, I never thought to try this before.
> Then, please show more of the build output of the failing build:
> everyth
--- Comment #3 from rwild at gcc dot gnu dot org 2009-09-21 07:46 ---
First off, do you happen to know whether this is a regression?
Then, please show more of the build output of the failing build:
everything starting from toplevel target 'configure-target-libgomp'.
You can recreate that
--- Comment #5 from burnus at gcc dot gnu dot org 2009-09-21 07:45 ---
> Thank you for your response. I would appreciate very much if you could you
> please supply me with a web site and the name of the particular version of
> binutils.
The generic place is http://www.gnu.org/software/b
--- Comment #20 from jakub at gcc dot gnu dot org 2009-09-21 07:01 ---
Wonder why gcc on darwin should always work around darwin toolchain bugs, but
on most other OSes if you have bugs in tools, you just require those bugs to be
fixed, gcc doesn't work around them. What is so special ab
83 matches
Mail list logo
