--- Comment #3 from ghazi at gcc dot gnu dot org 2007-05-18 02:31 ---
Subject: Bug 31796
Author: ghazi
Date: Fri May 18 01:31:20 2007
New Revision: 124820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124820
Log:
PR middle-end/31796
* builtins.c (do_mpfr_remquo)
While compiling xorg-server-1.3.0.0/hw/xfree86/scanpci/xf86ScanPci.c gcc goes
into an infinite loop eating up all memory. Compiling flags were: -g -O2
(defaults).
Output (with virtual memory limited to 512000k) follows.
make[1]: Entering directory `/opt/src/xorg-server-1.3.0.0/hw/xfree86/scanpci'
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-18 03:12
---
Created an attachment (id=13575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13575&action=view)
Possible patch for this problem
Daniel, Please try this patch and see if eliminates the segfault. TIA
--
--- Comment #2 from fang at csl dot cornell dot edu 2007-05-18 03:27
---
It's too bad the holy standard documents (ISO/IEC) aren't free or freely
distributable, they could be nice supplementary reference material to go along
with a compiler, even one that isn't perfectly standard adher
--- Comment #2 from rob1weld at aol dot com 2007-05-18 03:54 ---
I just read 29544 (against 4.2.0) - as you would say: "what was your (x)gcc -v
?".
I used
"--enable-stage1-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree"
and got these test results:
http://gcc.gnu.org/ml/gcc-t
--- Comment #1 from rob1weld at aol dot com 2007-05-18 03:57 ---
A recent compile of 4.2.1 with complaints about log file parsing at the end is
here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
--- Comment #1 from rob1weld at aol dot com 2007-05-18 04:01 ---
A recent gcc 4.2.1 compile (20070515 - revision 124745) for Linux is here:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31891
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-18 04:10 ---
I have no idea what you are talking about overwritting. In 4.1 and before the
subdirectory gcc's makefile handled bootstrap (staging). In 4.2 and above, the
toplevel makefile handles bootstrap. So that means we can
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-18 04:13 ---
(In reply to comment #1)
> A recent compile of 4.2.1 with complaints about log file parsing at the end is
> here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html
I bet you are using a bad expect which ca
--- Comment #2 from magnus_os at yahoo dot se 2007-05-18 05:41 ---
The OS is Fedora 6. The compiler was generated from source after doing a "svn
update". I made sure that no previous object code was present before
rebuilding. The CPU is a 32-bit AMD 3000.
--
http://gcc.gnu.org/bugzi
--- Comment #1 from pluto at agmk dot net 2007-05-18 06:08 ---
this is a dup of PR30052
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31984
--- Comment #4 from rob1weld at aol dot com 2007-05-18 05:57 ---
>> --- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] ---
>> I have no idea what you are talking about overwritting.
In the 4.1.1 AND 4.2.0/1 configure file we have:
--enable-bootstrap[=lean] Enable b
--- Comment #4 from ian at gcc dot gnu dot org 2007-05-18 06:37 ---
Subject: Bug 31953
Author: ian
Date: Fri May 18 05:37:27 2007
New Revision: 124823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124823
Log:
./:
PR tree-optimization/31953
* tree-vrp.c (set_valu
--- Comment #5 from ian at gcc dot gnu dot org 2007-05-18 06:40 ---
Subject: Bug 31953
Author: ian
Date: Fri May 18 05:40:21 2007
New Revision: 124824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124824
Log:
./:
PR tree-optimization/31953
* tree-vrp.c (set_valu
--- Comment #6 from ian at airs dot com 2007-05-18 06:53 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-18 06:53
---
A patch for this bug has been submitted for approval.
http://gcc.gnu.org/ml/fortran/2007-05/msg00314.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-18 07:05
---
I have Fedora 6 on x86-64. Works OK here. However, we have a leak. From
valgrind:
==19184== 9,288 (1,264 direct, 8,024 indirect) bytes in 2 blocks are definitely
lost in loss record 4 of 9
==19184==at 0x4A
--- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
The test case in comment #73 is just a standard aliasing violation. You are
casting a double* to an int* and writing to it both ways. As I argued in
comment #76, the only way this is going to work is if we eliminate TBAA in
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-18 07:18 ---
(In reply to comment #3)
> This fixes it and much more besides. It needs commenting and tidying up.
>
...but is broken on x86_ia64 with a very odd error message:
pr31879.f90: In function MAIN__:
pr31879.f90:13: in
--- Comment #79 from ian at airs dot com 2007-05-18 07:25 ---
The test case in comment #71 doesn't use placement new either.
This PR was originally about placement new. I think there is general agreement
thta placement new needs to avoid aliasing problem. I don't think there is
genera
--- Comment #80 from mark at codesourcery dot com 2007-05-18 07:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
> The test c
101 - 122 of 122 matches
Mail list logo
