I am not talking about a library solution at all. I am talking about a
solution inside the compiler. Gcc will optimize memcpy; how much for
MIPS is a good question. Try it out and see. Oh if you are using
scei's gcc you really should be reporting issues to them.
On Aug 31, 2010, at 10:03
--- Comment #9 from pinskia at gmail dot com 2010-09-01 06:17 ---
Subject: Re: Bad optimization in -O3 sometimes
I am not talking about a library solution at all. I am talking about a
solution inside the compiler. Gcc will optimize memcpy; how much for
MIPS is a good question. Try
No error is printed for:
call execute_command_line(date, .true.,(1),(1),('aa'))
end
although the third to fifth argument are declared as INTENT(INOUT) in
intrinsic.c and thus they have to be definable. The example is for
execute_command_line, but I think it applies to all intrinsics.
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 08:49 ---
This is partially subsumed by the other bug at PR45444
*** This bug has been marked as a duplicate of 45444 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 08:49 ---
*** Bug 44670 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2010-09-01 09:06 ---
r163260 only made this BB vectorizable.
I checked lookup_stmt_eh_lp for the last stmt of the BB and EDGE_EH flags
before and after vectorization (basic block SLP), and in both cases
lookup_stmt_eh_lp returns 0 and
--- Comment #6 from ramana at gcc dot gnu dot org 2010-09-01 09:07 ---
Leaving this open as per comment #4
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
I know I'm at least partly to blame for this :)
With a LTO bootstrap I get now
/home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode
streams do not support the target attribute
because of the new __target__ use in libcpp/lex.c
--
Summary: target use in
As the Fortran front-end now uses soft-float quad precision floating-point
types (__float128 and its complex counterpart), it would be nice for libgcc to
contain TFmode functions on Intel/darwin.
This is present on *86*-{linux,mingw,solaris} and ia64-{linux,hpux}. It was
recently introduced in
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-09-01 09:38 ---
The 'uninitialized const members' warning also affects cross builds when
using --enable-build-with-cxx, see PR44670
--
amylaar at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-01 09:42 ---
The problem is of course that the target and optimization attribute data
format is auto-generated. A solution would be to simply byte-copy
TREE_TARGET_OPTION with pre-pending its size and check the size on LTO
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-01 09:43 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-01 09:45
---
(In reply to comment #8)
Unfortunately, a lib based solutions are difficult for me to implement. The
reason is that the current PSP SDK uses newlib. I can probably change my
personal toolchain with some work,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #1 from ubizjak at gmail dot com 2010-09-01 10:12 ---
Intel/darwin already supports __float128.
--
ubizjak at gmail dot com changed:
What|Removed |Added
I know I'm at least partly to blame for this :)
With a LTO bootstrap I get now
/home/ak/gcc/git/gcc/libcpp/lex.c:2838:1: sorry, unimplemented: gimple bytecode
streams do not support the target attribute
because of the new __target__ use in libcpp/lex.c
--
Summary: target use in
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-01 10:14 ---
Working on a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:15 ---
Yes, I have most of a patch already, but will add the check value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-01 10:19 ---
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
and after:
bb 2:
/irun
--with-gmp=/Users/fx/devel/gcc/deps --enable-languages=c,fortran --without-ppl
Thread model: posix
gcc version 4.6.0 20100901 (experimental) [trunk revision 163721] (GCC)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2010-09-01 10:30 ---
(In reply to comment #2)
It partially does. But TC functions are missing:
Ah, I see. Put these defines somewhere:
/* Put all *tf routines in libgcc. */
#undef LIBGCC2_HAS_TF_MODE
#define LIBGCC2_HAS_TF_MODE 1
#define
Command line:
$ gcc -mno-sse testcase.c
or
$ gcc -m32 -march=i386 testcase.c
(or other target without sse support)
Compiler output:
$ gcc -mno-sse testcase.c
testcase.c:9: internal compiler error: in c_builtin_function_ext_scope, at
c-decl.c:2852
Please submit a full bug report,
with
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 10:31 ---
I'm not sure how well supported the old Linux target is with respect to the
Neon builtins. It never received much testing and probably needs work since
this target is in maintenance mode only.
--
ramana at gcc
--- Comment #1 from zsojka at seznam dot cz 2010-09-01 10:33 ---
Created an attachment (id=21632)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21632action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45478
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 10:34 ---
I'm not sure where this will be handled but I can see this with trunk today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** Bug 45477 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** This bug has been marked as a duplicate of 45475 ***
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #27 from jamborm at gcc dot gnu dot org 2010-09-01 11:10
---
As far as I understand it, this is fixed with
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00577.html
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-09-01 11:13 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #28 from jamborm at gcc dot gnu dot org 2010-09-01 11:23
---
Hm, no, I was too quick pruning my inbox. The patch apparently has
not been applied to the 4.5 branch.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from jamborm at gcc dot gnu dot org 2010-09-01 11:24
---
I'll do that, hopefully sooner rather than later.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from ibolton at gcc dot gnu dot org 2010-09-01 11:25
---
(In reply to comment #28)
Hm, no, I was too quick pruning my inbox. The patch apparently has
not been applied to the 4.5 branch.
It's on its way. I've been testing in conjunction with a couple of other
--- Comment #31 from jamborm at gcc dot gnu dot org 2010-09-01 11:32
---
(In reply to comment #30)
(In reply to comment #28)
Hm, no, I was too quick pruning my inbox. The patch apparently has
not been applied to the 4.5 branch.
It's on its way. I've been testing in
--- Comment #32 from jifl-bugzilla at jifvik dot org 2010-09-01 11:47
---
I don't know if there are plans for more releases in the 4.4 series, but can it
be applied to the 4.4 branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
--- Comment #33 from jakub at gcc dot gnu dot org 2010-09-01 11:50 ---
Yes, 4.4.5 and maybe 4.4.6 is planned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-01 11:53 ---
Subject: Bug 45321
Author: ramana
Date: Wed Sep 1 11:52:55 2010
New Revision: 163726
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163726
Log:
2010-09-01 Mikael Pettersson mi...@it.uu.se
PR
--- Comment #6 from irar at il dot ibm dot com 2010-09-01 11:54 ---
(In reply to comment #5)
I see before SLP:
bb 2:
MEM[(struct A *)this_1(D)].a = 0;
MEM[(struct A *)this_1(D)].b = 0;
MEM[(struct A *)this_1(D)].c = 0;
[LP 2] MEM[(struct A *)this_1(D) + 12B].a = 0;
--- Comment #8 from burnus at gcc dot gnu dot org 2010-09-01 12:01 ---
(In reply to comment #0)
Main program is written in C. (see the following)
I strongly suggest using the C Binding facility of Fortran 2003 instead of
relying on the internals of a given compiler. GCC/gfortran
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 12:02 ---
I think this is a variant of PR 42647: Allocatable components of allocatable
scalars are not correctly handled.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2010-09-01 12:03 ---
Fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-09-01 12:24
---
Subject: Bug 45353
Author: ebotcazou
Date: Wed Sep 1 12:24:35 2010
New Revision: 163731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163731
Log:
Backport from mainline
2010-08-20 Jakub
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-01 12:31 ---
(In reply to comment #3)
On x86_64-apple-darwin10 I have applied the following patch
--- ../_clean/gcc/config/i386/darwin.h 2010-07-19 11:51:25.0 +0200
+++ ../p_work/gcc/config/i386/darwin.h 2010-09-01
--- Comment #14 from ramana at gcc dot gnu dot org 2010-09-01 12:41 ---
Patches should be submitted to gcc-patc...@gcc.gnu.org. This is a 4.3 only
issue.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
[r...@localhost Desktop]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/apps/gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6-20100828/configure --prefix=/apps/gnu
--disable-bootstrap
--- Comment #1 from mikedalpee at enginsol dot com 2010-09-01 13:13 ---
Created an attachment (id=21633)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21633action=view)
Program that demonstrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #2 from mikedalpee at enginsol dot com 2010-09-01 13:13 ---
Created an attachment (id=21634)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21634action=view)
script that builds the bug program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-09-01 13:15 ---
No, I still get the same ICE (on both the reduced testcase and firefox
as such) even with a recent checkout of trunk (revision 163677 from
yesterday).
Not only I use the same version of gold but apparently also the
--- Comment #3 from mikedalpee at enginsol dot com 2010-09-01 13:16 ---
Created an attachment (id=21635)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21635action=view)
output of the bug program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #2 from zsojka at seznam dot cz 2010-09-01 13:23 ---
Created an attachment (id=21636)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21636action=view)
different testcase
This testcase crashes the same way with -mno-sse2. It was reduced from lex.i as
well.
$ gcc
--- Comment #4 from mikedalpee at enginsol dot com 2010-09-01 13:27 ---
Created an attachment (id=21637)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21637action=view)
Expected output of bug program - generated on Solaris 9 using Sun Studio 12.
--
On Linux/x86, revision 163680 gave
FAIL: gcc.dg/lto/20081201-2 c_lto_20081201-2_0.o-c_lto_20081201-2_1.o execute
-O3 -fwhopr
FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o
link, -O1 -fwhopr -fwhole-program
Revision 163670 is OK.
--
Summary: [4.6
--- Comment #5 from burnus at gcc dot gnu dot org 2010-09-01 13:31 ---
Cf. patch by Uros for cygming, darwin, freebsd at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00040.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
--- Comment #5 from mikedalpee at enginsol dot com 2010-09-01 13:32 ---
This bug occurs across all versions of the compiler I have tested - 4.3, 4.4,
4.5, and 4.6. The bug is preventing me from porting software, because correct
destructor excecution in a cancelled thread is fundamental
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-01 13:33 ---
Confirmed. Obviously Honzas.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
[r...@localhost exception1]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/apps/gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6-20100828/configure --prefix=/apps/gnu
--disable-bootstrap
--- Comment #6 from burnus at gcc dot gnu dot org 2010-09-01 13:35 ---
Uros, did you see the comment of Dominique regarding x86_64-apple-darwin10?
(In reply to comment #4)
and bootstrap fails at stage 1 with
ld: duplicate symbol ___fixtfdi in fixtfdi_s.o and _fixtfdi_s.o
That's with
--- Comment #1 from mikedalpee at enginsol dot com 2010-09-01 13:36 ---
Created an attachment (id=21638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21638action=view)
Program that demonstrates the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
--- Comment #2 from mikedalpee at enginsol dot com 2010-09-01 13:36 ---
Created an attachment (id=21639)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21639action=view)
script that builds the bug program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
--- Comment #3 from mikedalpee at enginsol dot com 2010-09-01 13:38 ---
Created an attachment (id=21640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21640action=view)
output of the bug program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-01 13:40 ---
I am sure this is more a pthread implementation issue, so a glibc bug
on sourceware.org/bugzilla would be more appropriate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #4 from mikedalpee at enginsol dot com 2010-09-01 13:41 ---
Created an attachment (id=21641)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21641action=view)
Expected output of bug program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45481
The error I get is the same as in the old pr 33130. I don't see why this is so.
Ian Lance Taylor suggested looking at STDC_HEADERS, and indeed in
libiberty/config.h it is defined in stage1, but not in stage2.
I am attaching a few config files; please let me know what else is needed to
figure
--- Comment #1 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21642action=view)
Main config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #2 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21643action=view)
stage 1 libiberty/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #3 from sfilippone at uniroma2 dot it 2010-09-01 13:44 ---
Created an attachment (id=21644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21644action=view)
stage 1 libiberty/config.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #4 from sfilippone at uniroma2 dot it 2010-09-01 13:45 ---
Created an attachment (id=21645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21645action=view)
stage 2 libiberty/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #5 from sfilippone at uniroma2 dot it 2010-09-01 13:45 ---
Created an attachment (id=21646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21646action=view)
stage 2 libiberty/config.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-01 13:49
---
For the record, building with ICC gives the same behavior of GCC. Let's ask
Jason' opinion about this.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-01 13:53
---
Likewise about ICC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
--- Comment #9 from Lulin dot Song at gmail dot com 2010-09-01 14:22
---
(In reply to comment #8)
(In reply to comment #0)
Main program is written in C. (see the following)
I strongly suggest using the C Binding facility of Fortran 2003 instead of
relying on the internals of a
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-01 14:26 ---
(In reply to comment #0)
Invalid read of size 1
I don't see this at r163721 (probably has been fixed by r159445).
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from burnus at gcc dot gnu dot org 2010-09-01 14:32 ---
(In reply to comment #9)
when the return value is character string, is it more intuitive to be
requestdouble ( real(kind=8) rlat, real(kind=8)
rlng,character(kind=1)[1:16] __result, integer(kind=4)
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-01 14:36 ---
Using 4.6.0 20100901 (experimental) [trunk revision 163720], I still see:
gfortran -g alloc_comp_scalar_1.f90 valgrind ./a.out
==14804== Invalid read of size 8
==14804==at 0x400B82: MAIN__ (alloc_comp_scalar_1
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-09-01
14:38 ---
Original -m32 lto testsuite failures due to non-relocatable subtraction
expression errors were made latent by the commit...
Author: ak
Date: Tue Aug 31 16:58:46 2010
New Revision: 163680
URL:
Original -m32 lto testsuite failures due to non-relocatable subtraction
expression errors were made latent by the commit...
Hmm, this does not make much sense. What changed?
Honza
--- Comment #31 from hubicka at ucw dot cz 2010-09-01 14:42 ---
Subject: Re: m32 lto produces non-relocatable subtraction
expression errors
Original -m32 lto testsuite failures due to non-relocatable subtraction
expression errors were made latent by the commit...
Hmm, this
--- Comment #31 from hjl dot tools at gmail dot com 2010-09-01 14:51
---
(In reply to comment #30)
With only gcc-pr45234-2.patch at r163712 , I am seeing the following
regressions...
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os
(internal
compiler error)
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-01 14:54 ---
With r163667 and fixes for PR45444 applied I don't see issues with a v7-a
bootstrap. Can we see if a later version works for you ?
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed
I checked what options are being chosen on one of my laptops following the
following instructions:
http://en.chys.info/2010/04/what-exactly-marchnative-means/
But, when reviewing used options I got:
$ ps af | grep cc1
18118 pts/1S+ 0:00 \_ grep --colour=auto cc1
18116 pts/0S+
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2010-09-01
15:18 ---
(In reply to comment #31)
I compared revision 163733 against revision 163733 + gcc-pr45234-2.patch
with a cross compiler to x86_64-apple-darwin10.4.0. I saw no
differences in .su files for
--- Comment #11 from Lulin dot Song at gmail dot com 2010-09-01 15:29
---
(In reply to comment #10)
(In reply to comment #9)
when the return value is character string, is it more intuitive to be
requestdouble ( real(kind=8) rlat, real(kind=8)
rlng,character(kind=1)[1:16]
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2010-09-01
15:30 ---
Created an attachment (id=21647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21647action=view)
Don't redefine STACK_BOUNDARY and replace STACK_BOUNDARY with 128.
--
howarth at nitro dot med dot
--- Comment #34 from hjl dot tools at gmail dot com 2010-09-01 15:31
---
(In reply to comment #33)
Created an attachment (id=21647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21647action=view) [edit]
Don't redefine STACK_BOUNDARY and replace STACK_BOUNDARY with 128.
Please
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2010-09-01
15:37 ---
(In reply to comment #34)
Please do a proper regression test and report REAL regressions.
First we need to do a regression hunt in gcc trunk for the new
stack test case failures. It is impossible to
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-01 15:40 ---
Please try gcc 4.5.2 and report what it does.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from pacho at condmat1 dot ciencias dot uniovi dot es
2010-09-01 15:51 ---
gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about
installing it :-/, are you sure this bug could be solved in 4.5* ?
--
pacho at condmat1 dot ciencias dot uniovi dot es
--- Comment #2 from hubicka at ucw dot cz 2010-09-01 15:56 ---
Subject: Re: [4.6 Regression] New LTO failures
Confirmed. Obviously Honzas.
I had no commits in the specified range ;)
It seems that Andi's patch just disable whopr...
Honza
--
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-01 15:56 ---
(In reply to comment #2)
gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about
installing it :-/, are you sure this bug could be solved in 4.5* ?
1. -march=native is changed in gcc 4.5.
2.
--- Comment #4 from pacho at condmat1 dot ciencias dot uniovi dot es
2010-09-01 16:06 ---
(In reply to comment #3)
(In reply to comment #2)
gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about
installing it :-/, are you sure this bug could be solved in 4.5* ?
...
FAIL: gcc.dg/stack-usage-1.c scan-file foo\\t(256|264)\\tstatic
FAIL: gcc.target/i386/stack-usage-realign.c scan-file
main\\t48\\tdynamic,bounded
at -m32 as well. The sprintf error appears as...
/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100901/gcc/testsuite/gcc.c-torture/execute/builtins/sprintf
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-01
16:21 ---
Original patch submitted with
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00440.html.
Test cases added with http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00503.html.
--
howarth at nitro dot med dot uc
On a system with more than 8 cores the following program causes an interprocess
deadlock if started twice. This Problem has been observed on following systems:
2 IntelCPUs with 4 Cores per CPU; 2 IntelCPUs with 6 Cores per CPU; 1 IntelCPUs
with 6 Cores per CPU and Hyperthreading on (results in 12
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-01 16:37 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
gcc-4.5 is still hardmasked downstream in Gentoo, then, I am unsure about
installing it :-/, are you sure this bug could be solved
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-01 16:38 ---
*** This bug has been marked as a duplicate of 43706 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from jakub at gcc dot gnu dot org 2010-09-01 16:38 ---
*** Bug 45485 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 167 matches
Mail list logo
