--- Comment #3 from pcarlini at suse dot de 2008-03-09 11:21 ---
I agree ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from ubizjak at gmail dot com 2008-03-09 11:39 ---
Patch in testing:
Index: i386.c
===
--- i386.c (revision 133051)
+++ i386.c (working copy)
@@ -16789,7 +16789,8 @@
int
ix86_constant_alignment
--- Comment #2 from hutchinsonandy at aim dot com 2008-03-09 12:23 ---
Here is more info:
Testcase:
static long foo99(long b,long a)
{
return b * a;
}
long foo2(long b, long a)
{
return foo99(b,a);
}
Looking at RTL, the USE of the respective libcalls are
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-09 13:33 ---
Hmm, we indeed cannot communicate to the backend (or register allocator) that
function arguments of a libcall are communtative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
--- Comment #9 from uros at gcc dot gnu dot org 2008-03-09 13:38 ---
Subject: Bug 35496
Author: uros
Date: Sun Mar 9 13:37:52 2008
New Revision: 133052
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133052
Log:
PR target/35496
* config/i386/i386.c
--- Comment #10 from hjl dot tools at gmail dot com 2008-03-09 14:06
---
Can we add a few testcases for Linux/ia32?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
--- Comment #2 from marcus at better dot se 2008-03-09 14:46 ---
BTW this bug makes TestNG fail horribly with gcj, it relies heavily on
reflection with annotations of this kind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35253
Compiler wants to know:
1. If a symbol will be referenced locally within the file. If a readonly
symbol with initializer is referenced with the file, compiler may
replace symbol read with its initializer. PRs 35402/35494/35501.
2. If a symbol will be referenced locally within the module, an
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-09 15:16 ---
We can add a parameter to indicate for read, write and branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35513
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-03-09 15:42 ---
Still fails in 4.2.x:
http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00510.html
http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00457.html
I don't see the error with the 4.3 branch:
--- Comment #7 from jwakely dot gcc at gmail dot com 2008-03-09 15:51
---
Created an attachment (id=15284)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15284action=view)
make nested iterator typedefs private in debug mode
It's accepts implementation-defined not accepts invalid -
Gcc doesn't generate symbol types for undefined symbol on ELF targets:
bash-3.2$ cat x.c
extern void foo() __attribute__((weak,visibility(hidden)));
extern int puts( char const* );
int main()
{
foo ? foo() : puts( foo == null, skipped. );
return 0;
}
bash-3.2$ gcc -c x.c
bash-3.2$
--- Comment #8 from jwakely dot gcc at gmail dot com 2008-03-09 15:52
---
Created an attachment (id=15285)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15285action=view)
new test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-03-09 16:07 ---
On 4.3.x, this failure goes away sometime on 20070322. Luckily we had two
testsuite results on the same day hours apart from one person in which the
failure disappears. :-)
--- Comment #5 from ubizjak at gmail dot com 2008-03-09 16:17 ---
IIRC, this is a testsuite issue, -march=i486 is not appended automatically to
compile flags. This was fixed by following patch series:
2007-04-07 John David Anglin [EMAIL PROTECTED]
PR testsuite/31369
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-03-09 16:51
---
This is one of the issues that I originally tried to fix for 4.3:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01661.html
but that was too invasive for stage 3. I resubmitted it after 4.4 opened:
I'll attach a testcase.
--
Summary: asm() makes gcc forget about conditionally initialized
values
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2008-03-09
17:02 ---
Erf, sorry, asm constraint problem.
--
samuel dot thibault at ens-lyon dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2008-03-09 17:09 ---
(In reply to comment #10)
Can we add a few testcases for Linux/ia32?
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00585.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
Hi
***
unsigned long long foo=0;
int main (void)
{
foo=0;
return 0;
}
***
[EMAIL PROTECTED]:~/dev/C/test4$ gcc -Wall -save-temps -march=opteron
-masm=intel
test1.c -o intel_asm_sample
test1.s: Assembler messages:
test1.s:19:
--- Comment #4 from hutchinsonandy at aim dot com 2008-03-09 18:36 ---
The problem is not commutation knowledge to the backend.
First - the use notes were a red herring. Reversing them did not help.
After much chasing thru call.c and optabs.c, it looks like neither creates nor
correct
--- Comment #23 from t dot artem at mailcity dot com 2008-03-09 19:03
---
Since GCC 4.3.0 is out and this bug is no longer reproducible I suppose it's
worth marking this bug as FIXED.
Wow, it took exactly two years to fix this bug :-)
--
t dot artem at mailcity dot com changed:
--- Comment #12 from dominiq at lps dot ens dot fr 2008-03-09 19:32 ---
On i686-apple-darwin9 the commited patch of comment #8 fixes the failure for
gfortran.dg/array_constructor_12.f90 -O3, but not the failures for
gcc.dg/bf-ms-layout*.c which require the patch from comment #5.
--
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-09 19:39 ---
Subject: Bug 35474
Author: pault
Date: Sun Mar 9 19:38:51 2008
New Revision: 133063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133063
Log:
2008-03-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-03-09 19:40 ---
(In reply to comment #5)
IIRC, this is a testsuite issue, -march=i486 is not appended automatically to
compile flags. This was fixed by following patch series:
[...]
Uros - It would seem that the first patch
The attached program is a straightforward implementation of matrix inversion
via the Gauss-Jordan algorithm. The explicitly parallelized version (not
attached) produces exactly the same result for each run independent of the
number of threads. The version parallelized via OpenMP produces incorrect
--- Comment #1 from bart dot vanassche at gmail dot com 2008-03-09 19:58
---
Created an attachment (id=15286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15286action=view)
Test program matinv_openmp.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35517
--- Comment #9 from chris at bubblescope dot net 2008-03-09 20:28 ---
Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've
previously tended to assume that _GLIBCXX_DEBUG should change only flag code
that should fail in non-debug mode, but fails to be detected,
--- Comment #7 from ubizjak at gmail dot com 2008-03-09 20:55 ---
(In reply to comment #6)
Uros - It would seem that the first patch written by you and installed on
3/22/2008 was sufficient to fix the problem on x86_64. What was the need for
the others, relevant towards this PR?
--- Comment #13 from ubizjak at gmail dot com 2008-03-09 21:26 ---
(In reply to comment #12)
On i686-apple-darwin9 the commited patch of comment #8 fixes the failure for
gfortran.dg/array_constructor_12.f90 -O3, but not the failures for
gcc.dg/bf-ms-layout*.c which require the patch
--- Comment #14 from hjl dot tools at gmail dot com 2008-03-09 21:48
---
Does MS bitfield struct require 8byte alignment for long long field
for 32bit target?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
--- Comment #9 from danglin at gcc dot gnu dot org 2008-03-09 21:54 ---
pr11832.c and pr33009.c are also failing on hppa2.0w-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hjl dot tools at gmail dot com 2008-03-09 21:54
---
We may need to update ADJUST_FIELD_ALIGN to support MS-bitfield.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35496
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20040709-1.c -w -O2
-fno-s
how-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/20040709-1.x2
(ti
meout = 300)
PASS: gcc.c-torture/execute/20040709-1.c
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-03-09 23:30 ---
Subject: Bug 35190
Author: kkojima
Date: Sun Mar 9 23:29:49 2008
New Revision: 133064
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133064
Log:
Backport from mainline:
PR target/35190
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-03-09 23:32 ---
Subject: Bug 35225
Author: kkojima
Date: Sun Mar 9 23:31:26 2008
New Revision: 133065
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133065
Log:
Backport from mainline:
PR target/35225
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-03-09 23:40 ---
Subject: Bug 35225
Author: kkojima
Date: Sun Mar 9 23:39:51 2008
New Revision: 133066
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133066
Log:
Backport from mainline:
PR target/35225
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-03-09 23:44 ---
fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-03-09 23:45 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from danglin at gcc dot gnu dot org 2008-03-09 23:47 ---
Also fails on hppa2.0w-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
This problem potentiall affects all all targets
The data flow information that combine uses can cause Segmentation fault. I
have found this with AVR experimental build but it would seem that it can
affect any target.
The problem is that the LOG_LINKS that combine creates from DF can include
--- Comment #1 from hutchinsonandy at aim dot com 2008-03-09 23:52 ---
Created an attachment (id=15287)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15287action=view)
Patch for consideratiom towards a solution
Patch that removes duplicates when LOG_LINKS is created.
--
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-03-10 00:08
---
If it is just the test case I will attempt to fix it. If anyone else is
already doing so, please let me know so I don't waste my time. :)
--
jvdelisle at gcc dot gnu dot org changed:
What
--- Comment #3 from manu at gcc dot gnu dot org 2008-03-10 00:37 ---
@Adam,
If you think that something is wrong in the documentation, please point out
exactly which text should be removed and what should be added. Also, feel free
to submit a documentation patch:
--- Comment #4 from manu at gcc dot gnu dot org 2008-03-10 00:52 ---
(In reply to comment #2)
Actually, I like that response. I might try to use it myself next time one of
our customers reports a problem.
I guess that your contracted GCC support developers may give you a reply
--- Comment #3 from gerald at pfeifer dot com 2008-03-10 01:35 ---
(In reply to comment #2)
Based on the command line it looks like your system gjar is crashing.
Is that the case?
Good point. Yes, that seems to be the case, and I asked Richi about it.
--
gerald at pfeifer dot
--- Comment #2 from Kenneth dot Zadeck at NaturalBridge dot com 2008-03-10
01:48 ---
I tested the latest patch on ppc-32 and ppc-64 and there were no regressions.
i did have trouble applying the patch. The second frag of the update for the
test case did not apply.
--
Kenneth dot
i am trying to build gcc-3.4.4 on solaris -10..i am getting an error in the
build stage
csbu061 [toolsrd] 703: make build
creating cache ./config.cache
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking build system type...
48 matches
Mail list logo
