--- Comment #18 from jakub at gcc dot gnu dot org 2010-01-25 08:22 ---
It is no longer marged regression, so no longer release critical.
Anyway, the goal should be to reenable the asserts in dwarf2out.c and fix the
issues, because they really result in wrong unwind info. Only the unwind
--- Comment #8 from mario-baumann at web dot de 2010-01-25 08:24 ---
Hi Jonathan, thanks for the hint!
I attached a version (goo.cpp) without boost.
> g++ -c goo.cpp
goo.cpp: In member function 'void Eval::eval(int_<0>) [with int V = 0, T =
Mtrl]':
goo.cpp:42:9: instantiated from 'vo
--- Comment #9 from mario-baumann at web dot de 2010-01-25 08:26 ---
Created an attachment (id=19702)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19702&action=view)
new c++ source file (independent of boost)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 08:30 ---
(In reply to comment #3)
> Today I am not able to reproduce the error. The compiler is working. Where
> exactly does the file m.mod reside? In the user directory or in a compiler
> directory?
By default in the curren
--- Comment #5 from frank dot braun at rz dot uni-regensburg dot de
2010-01-25 08:36 ---
've got it. Modifying the .mod file by hand makes the compiler crash. Deleting
it lets it work correctly.
The compiler shouldn't crash anyway. But with a new version this problem should
be solved t
--- Comment #2 from mikpe at it dot uu dot se 2010-01-25 09:33 ---
I had very recently updated binutils from 2.19.1 to 2.20 + branch updates +
some fixes from trunk. Going back to binutils 2.19.1 while changing nothing
else eliminated the StackTrace2 and Throw_3 failures from gcc-4.3.
M
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 09:37 ---
(In reply to comment #3)
> This appears to fix this: regression tested on x86-64
I think the following patch is better. My intrinsic check was bogus.
Index: array.c
==
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-25 09:56 ---
Confirmed. Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-25 10:06 ---
I suppose this is from rths exception rewrite.
void start (void);
void ptw32_terminate (void)
{
try {
start ();
}
catch( int ) { }
catch( int ) { }
}
--
rguenth at gcc dot gnu dot org changed:
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10
---
Ok, I see that asking was a good idea, the tangle of issues is quite complex.
Anyway, this is my current proposal: let' use for now your mildly optimized and
in any case correct solution using a loop of char-wi
--- Comment #4 from bugs at 59A2 dot org 2010-01-25 10:33 ---
(In reply to comment #3)
> So it's gfortran's fault you write non-portable code, and instead
> of dealing with it on your end, you think that gfortran developers
> should do the work to make your code compile.
Actually, gfort
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-25 10:38 ---
I understand that the bootstrap problem is PR 42836 and is now fixed
(thanks for that). SRA now removes the structures in the testcase
from bug description and so I consider this to be fixed.
--
jamborm at gcc d
PR37815 introduced a regression - no decls are tracked in spill slots, as they
have MEM_EXPR set to get_spill_slot_decl (false) instead of the real decl.
On the testcase I'm going to attach, the tok argument is (and clearly has to
be) live through the whole function except maybe last few instructio
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 11:45 ---
Created an attachment (id=19703)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19703&action=view)
parsetok.c.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 12:03 ---
This is completely undocumented attribute, so you first need to get Apple to
actually document what it does and get the documentation into doc/extend.texi.
Especially nothing explains the relationship between weak attr
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
--- Comment #9 from ramana at gcc dot gnu dot org 2010-01-25 12:29 ---
Subject: Bug 38697
Author: ramana
Date: Mon Jan 25 12:29:25 2010
New Revision: 156206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156206
Log:
Backport target/38697
Backport from trunk.
2010
--- Comment #10 from ramana at gcc dot gnu dot org 2010-01-25 12:30 ---
Fixed on branch .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-25 12:53 ---
> This is completely undocumented attribute ...
What is the "undocumented attribute"? If you mean
"-fno-asynchronous-unwind-tables", you don't need it for the tests to fail.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-25 12:59 ---
I mean that
grep weak_import doc/*
yields nothing at all (and google for weak_import doesn't show up any useful
documentation either).
It seems that Geoff Keating's implementation of the attribute (how could it be
comm
--- Comment #2 from ro at gcc dot gnu dot org 2010-01-25 14:54 ---
Subject: Bug 41522
Author: ro
Date: Mon Jan 25 14:54:15 2010
New Revision: 156213
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156213
Log:
PR testsuite/41522
* gcc.c-torture/compile/pr38789.c: C
--- Comment #3 from ro at gcc dot gnu dot org 2010-01-25 14:55 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Comment #4 from ro at gcc dot gnu dot org 2010-01-25 14:56 ---
Fixed for 4.5.0:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01255.html
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-25 16:22 ---
Subject: Bug 42858
Author: burnus
Date: Mon Jan 25 16:21:42 2010
New Revision: 156214
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156214
Log:
2010-01-25 Tobias Burnus
PR fortran/42858
*
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-25 16:24 ---
And FIXED. Thanks a lot for the report and sorry for breaking the code!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenther at suse dot de 2010-01-25 16:29 ---
Subject: Re: Revisit std::function for aliasing
issues
On Mon, 25 Jan 2010, paolo dot carlini at oracle dot com wrote:
> --- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10
> ---
> Ok, I
--- Comment #4 from uramakrishna at gmail dot com 2010-01-25 16:30 ---
Created an attachment (id=19704)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19704&action=view)
A further reduced case to show the ICE
Unable to find non-zero value for 'known_niter'.
--
http://gcc.gnu.o
GCC Version: 3.4.4 and 4.1.2
The GNU 4.1.2 C++ compiler is not generating the proper typedef DIEs in the
DWARF data.
For example, the type definition BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following DWAR
--- Comment #5 from amonakov at gcc dot gnu dot org 2010-01-25 17:06
---
We fail to find number of iterations after rewriting reductions out of SSA.
Before graphite pass, IR looks like (for the previous testcase, "pr42771.c"):
:
# j_26 = PHI
:
# j_33 = PHI
D.2747_16 = B[j_33]
--- Comment #2 from zsojka at seznam dot cz 2010-01-25 17:34 ---
Since:
r155937 | rguenth | 2010-01-15 12:53:26 +0100 (Fri, 15 Jan 2010) | 10 lines
2010-01-15 Richard Guenther
PR middle-end/42739
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-25 17:36
---
Ageeed. Indeed, I see there is a discussion ongoing. In the present time frame
let's figure out something minimally invasive, decently (if not perfectly)
optimized, and minimally coupled one way or the other to
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-01-25 17:51
---
(In reply to comment #6)
> I think if we get the old SRA behavior back for this code, we will get this
> optimization in 4.5 since we remove the sptr->base and the other unnecessary
> store during PRE.
>
We now s
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-01-25 18:01
---
Subject: Bug 36101
Author: amylaar
Date: Mon Jan 25 18:01:29 2010
New Revision: 156218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156218
Log:
PR libstdc++/36101, PR libstdc++/42813
* co
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 ---
Subject: Bug 42813
Author: amylaar
Date: Mon Jan 25 18:01:29 2010
New Revision: 156218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156218
Log:
PR libstdc++/36101, PR libstdc++/42813
* conf
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-01-25 18:02 ---
Since PR 42585 is fixed, the optimized dump (at -O2) is
:
_T2$curr_12 = sptr_1(D)->curr;
D.1966_7 = _T2$curr_12 + -1;
sptr_1(D)->curr = D.1966_7;
return 0;
}
The generated assembly is:
Cyc_string_ungetc:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-25 18:24 ---
On i?86-linux -fomit-frame-pointer is not the default, on the contrary.
info gcc says:
`-O' also turns on `-fomit-frame-pointer' on machines where doing
so does not interfere with debugging.
and i?86-linux is
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-01-25 18:30 ---
I have found the sentence you quoted in the manual too but it refers
only to -O1 (as far as I understand it). And the description of
-fomit-frame-pointer simply states that "Enabled at levels -O, -O2,
-O3, -Os." So
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 ---
This works with gcc 4.3 and 4.4 I don't have mainline lying around
here but if it really fails there it would be a 4.5 regression
which should get it P1 status. Can someone try?
W.
--
bangerth at gmail dot com chang
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 ---
Someone on a win64 machine may have to check this.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
This is a general m68k code generation regression. Starting with revision
150588 GCC for m68k generates "surprising" code for auto increments, eg.
for a strlcpy implementation. Compiling this code with the 4.5.0 snapshot
from 20100107 yields:
-- 4.5.0 --
_strlcpy:
movel d3,s...@-
--- Comment #11 from redi at gcc dot gnu dot org 2010-01-25 19:44 ---
Confirmed
pr42824.cc: In member function void Eval::eval(int_<0>) [with int V = 0, T
= Mtrl]:
pr42824.cc:42:9: instantiated from void Eval::eval() [with int V = 0, T =
Mtrl]
pr42824.cc:65:20: instantiated from
--- Comment #2 from schwab at linux-m68k dot org 2010-01-25 19:44 ---
m68k-unknown-amigaos is not a valid target.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
-
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-25 19:46 ---
Mine. Got a patch.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #12 from redi at gcc dot gnu dot org 2010-01-25 19:47 ---
CC'ing a release manager
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc.g
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-01-25
20:20 ---
Mike Stump's comment on Geoff's implementation of the attribute weak_import in
FSF gcc is...
> Not earth shattering, it just sets .weak_definition or .weak_reference for
> the assembler. google can find t
$ cat test.cpp
#include
int main()
{
std::string( (unsigned) 2, (unsigned) 'M' );
}
$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-langua
--- Comment #1 from kasey dot erickson at gmail dot com 2010-01-25 20:23
---
Created an attachment (id=19705)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19705&action=view)
preprocessed file
output from -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-01-25 21:10 ---
First, something has gotten better; an arm-eabi gcc (-O2 -std=c99 -mcpu=arm9
-funroll-loops) from 20091209 gives:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
For this code:
program F03_2_9_4_1_1a
implicit none
logical :: fail = .false.
call sub1(fail)
if (fail) stop 1
contains
subroutine sub1(fail)
use omp_lib
implicit none
integer, parameter :: NT = 4
logical :: fail
integer :: i
real, allocatable, save :: A(:)
re
--- Comment #2 from redi at gcc dot gnu dot org 2010-01-25 21:29 ---
*** This bug has been marked as a duplicate of 42261 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from redi at gcc dot gnu dot org 2010-01-25 21:29 ---
*** Bug 42864 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
For this test case:
program F03_2_9_3_6_2c
! derived from OpenMP test omp3f/F03_2_9_3_6_2c.f90
! REFERENCES
! OpenMP 3.0, p. 100, lines 10-12
! OpenMP 3.0, p. 316, lines 18-22
use omp_lib
implicit none
integer, parameter :: NT = 4
integer :: thread_num1, thread_num2, thread_num
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-25 21:59 ---
> Mike Stump's comment on Geoff's implementation of the attribute weak_import in
> FSF gcc is...
Could you give a pointer?
The first test was introduced by this patch
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg0
The problem is that the definition of isfinite() macro is not consistent
between version of GCC 4.3.3 and 4.4.1.
Simple test program:
include
#ifdef isfinite
#error isfinite defined
#else
#error isfinite NOT defined
#endif
int main() { return 0; }
1) Test with GCC 4.4.1 (Ubuntu 9.10 x86-64)
m
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-25 22:26 ---
isfinite is C99 only.
Plus math.h is controlled by libc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-25 22:30
---
Boy, this curious way of constructing strings seems rather fancy lately ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
--- Comment #2 from mateusz at loskot dot net 2010-01-25 22:34 ---
(In reply to comment #1)
> isfinite is C99 only.
Yes, of course it is and I understand it, but I'm trying to understand why the
GCC 4.3 and 4.4. behave differently?
Does it mean GCC 4.4 makes C99 elements available witho
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-25 22:37 ---
It depends. But really you did report it to us rather than Ubuntu first as
both are modified versions of GCC. Also you should look to see if they are
using the same version of glibc. Because maybe glibc was fixed
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-26 00:40
---
Created an attachment (id=19706)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19706&action=view)
Proposed patch to fix the problem
Patch to add 3 new switches to tune whether to use a combination of sqrt/cb
The following test case ICEs gcc-4.4.3 on sparc64 when compiled with -fPIC -m64
and any optimization level >= -O1.
> cat cpu_stats.i
extern int end, etext, edata;
long util_print_cpu_stats(void)
{
long vm_text, vm_init_data, vm_uninit_data, vm_sbrk_data;
vm_text = (long) (((long) (&etext
--- Comment #1 from mikpe at it dot uu dot se 2010-01-26 01:36 ---
Created an attachment (id=19707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19707&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
The Itanium code for GOMP_start_critical starts
0x20334900 :
[MMI] alloc r16=ar.pfs,1,1,0
0x20334901 : addl r32=840,r1
0x20334902 : nop.i 0x0
0x20334910 :[MMI] mf;;
0x20334911 :mov.m ar.ccv
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:20:27 2010
New Revision: 156229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156229
Log:
fix PR target/42841
Modified:
trunk/gcc/ChangeLog
trunk
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:21:57 2010
New Revision: 156230
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156230
Log:
fix PR target/42841
Modified:
branches/gcc-4_4-branch/gcc/C
--- Comment #13 from chrbr at gcc dot gnu dot org 2010-01-26 07:28 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:28:05 2010
New Revision: 156231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156231
Log:
fix PR target/42841
Modified:
branches/gcc-4_3-branch/gcc/C
--- Comment #14 from chrbr at gcc dot gnu dot org 2010-01-26 07:29 ---
fixed in 4.5, 4.3 and 4.4
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-26 07:59
---
It even fails with -m32 for me. Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
69 matches
Mail list logo
