--- 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
--- 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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
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'
--- 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)
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-18 02:15 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:15:28 2007
New Revision: 124819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124819
Log:
PR middle-end/30251
* builtins.c (fold_builtin_1)
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-05-18 02:04 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:04:12 2007
New Revision: 124818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124818
Log:
PR middle-end/30251
* builtins.c (do_mpfr_bessel_
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-18 01:13 ---
> Alternatively, or in combination, gcc could provide references to more
> widely-available sources (such as K&R and H&S for C, and Stroustrup or the ARM
> for C++ for example).
Except those are very unofficial when
As a supplement to the -- by necessity -- terse error messages generated by
gcc, it would be fantastic (IMHO) if a new option could be added to gcc to
display the current language standard along with the _section_ in that standard
that the error applies to.
IE, rather than...
hello.c:1:10: error:
This testcase should pass:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-forwprop" } */
/* We should be able to optimize this to b->t[i] = 1 during
early optimizations. */
struct a
{
char t[10];
};
struct a *b;
void f(__SIZE_TYPE__ i)
{
int *c = b->t;
c[i] = 1;
}
/* { dg-
--- Comment #15 from tim at klingt dot org 2007-05-18 00:06 ---
4.2.0 still has this bug ... maybe someone with enough power can add this to
the "known to fail" section?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Closing.
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-05-17
23:59 ---
Fixed by:
2007-05-17 Danny Smith <[EMAIL PROTECTED]>
PR target/31965
* config/i386/mingw32.h (_INTEGRAL_MAX_BITS): Define builtin as
TYPE_PRECISION (intmax_type_node).
--
--- Comment #2 from dannysmith at gcc dot gnu dot org 2007-05-17 23:51
---
Subject: Bug 31965
Author: dannysmith
Date: Thu May 17 22:51:05 2007
New Revision: 124813
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124813
Log:
PR target/31965
* config/i386/mingw32.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31981
This testcase should pass:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-forwprop" } */
/* We should be able to optimize this to b.t[i] = 1 during
early optimizations. */
struct a
{
int t[10];
};
struct a b;
void f(__SIZE_TYPE__ i)
{
int *c = b.t;
c[i] = 1;
}
/* { dg-fina
--- Comment #6 from brooks at gcc dot gnu dot org 2007-05-17 22:45 ---
Yeah, this is to be expected, I think. Holleriths store the memory
representation but not the "semantic" representation of their value, and
transfer tries to fold things and gets confused.
There's probably an easy f
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from sje at gcc dot gnu dot org 2007-05-17 21:29 ---
Subject: Bug 31850
Author: sje
Date: Thu May 17 20:29:34 2007
New Revision: 124810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124810
Log:
PR target/31850
* reload.c (subst_reloads): Remove ch
--- Comment #9 from andreast at gcc dot gnu dot org 2007-05-17 21:16
---
I'll take it over and apply it to gcc-head and classpath. Tom did approve it.
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 20:48 ---
I don't think you want the options to be in the MASK anyways.
Use Var(a, 0) Var(a, 1) Var(a, 2) etc. instead and that should fix your ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-17 20:45 ---
(In reply to comment #5)
> Both the C99 standard (section 5.1.2.2.3) and the C++ standard (3.6.1/5)
> say that if you hit the end of the main() function, then this is equivalent
> to a "return 0;" statement.
C90 is
--- Comment #5 from bangerth at dealii dot org 2007-05-17 20:38 ---
Both the C99 standard (section 5.1.2.2.3) and the C++ standard (3.6.1/5)
say that if you hit the end of the main() function, then this is equivalent
to a "return 0;" statement.
W.
--
bangerth at dealii dot org chang
In an arm target which is not in gcc svn (see http://gccsdk.riscos.info/) we
have the following options defined in its .opt file:
--8<--
mlibscl
Target Report RejectNegative InverseMask(UNIXLIB,LIBSCL)
Compile with the SharedCLibrary headers
munixlib
Target Report RejectNegative Mask(UNIXLIB)
Com
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-17 20:27 ---
> I can not reproduce the segfault, so if I can get a backtrace it would help.
Jerry, I hope this helps. Let me know if you need something else :)
$> gfortran-svn -v
gcc version 4.3.0 20070517 (experimental)
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-17 20:15 ---
Dominique, target-memory.c (frame #1 in the backtrace) was newly introduced at
20070516.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31972
C:\mingw\bugs>type bug.f90
subroutine dummy
contains
function quadric(a,b) result(c)
intent(in) a,b; dimension a(0:3),b(0:3),c(0:9)
c(0)=a(0)*b(0); c(1:3)=a(1:)*b(0)+a(0)*b(1:); c(4:6)=a(1:)*b(1:)
c(7:9)=(/a(1)*b(2)+b(1)*a(2),a(1)*b(3)+b(1)*a(3),a(2)*b(3)+b(2)*a(3)/)
end function
end
C:\m
--- Comment #14 from sje at cup dot hp dot com 2007-05-17 18:54 ---
Created an attachment (id=13574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13574&action=view)
reduced test case
Here is a reduced test case. I think the problem is related to having the
optimizer remove the g
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-17 18:53 ---
[pinskia-laptop:~/src] pinskia% gcc -Wreturn-type t.c
t.c: In function 'main':
t.c:15: warning: control reaches end of non-void function
This code is only undefined at runtime which means you cannot error out.
--
--- Comment #2 from clemens dot koller at anagramm dot de 2007-05-17 18:41
---
Created an attachment (id=13573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13573&action=view)
preprocessed file
It's just big. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31979
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 18:39 ---
This code is undefined as the warning points out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The host machine is a mpc8540 embedded PowerPC (e500 core)
$ uname -a
Linux ecam.anagramm.de 2.6.21-rc5-g9a5ee4cc #4 Mon Apr 2 21:31:53 CEST 2007 ppc
e500 GNU/Linux
Sources (just in case):
http://www.openssl.org/source/openssl-0.9.8e.tar.gz
It fails when compiling the file: openssl-0.9.8e/apps/oc
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-17 18:15 ---
This was fixed with the same patch that fixed PR 29841.
*** This bug has been marked as a duplicate of 29841 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-17 18:18 ---
Works for me on OSX 10.3.9 gfortran 4.3.0 20070511:
PROGRAM lsstr
INTEGER, DIMENSION(1) :: i
i = (/ TRANSFER(4HSOLR, 0) /)
print *, i
END PROGRAM lsstr
outputs 1397705810 (83797682 hexa) with gfortran, xlf, and g95,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #21 from pinskia at gcc dot gnu dot org 2007-05-17 18:15
---
*** Bug 30815 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-17 17:59 ---
Add Brooks to CC, again.
Brooks, could you have a look at this one?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from amylaar at gcc dot gnu dot org 2007-05-17 17:50 ---
(In reply to comment #2)
> Do you still have the testcase?
>
Not as such. However, AFAICR it was triggered by a regression test
(i.e. building library or testcase).
But the issue should be clear enough without a
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-17 17:46 ---
and this is exactly the way -x should behave. the documention is clear at
that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-17 17:33 ---
Confirmed. Adding Brooks Moses to CC as he recently worked on this.
(gdb) bt
#0 gfc_internal_error (
format=0x86ca3bc "Invalid expression in gfc_target_expr_size.")
at ../../../gcc/gcc/fortran/error.c:820
#
--- Comment #5 from bkoz at gcc dot gnu dot org 2007-05-17 17:22 ---
Also an issue with class templates.
See this thread:
http://gcc.gnu.org/ml/libstdc++/2007-05/msg00113.html
I'm changing this to normal severity, since we absolutely need a solution
pronto on this, as it is essential
--- Comment #3 from bmcfadden at cdp dot com 2007-05-17 16:54 ---
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-s
--- Comment #2 from bmcfadden at cdp dot com 2007-05-17 16:52 ---
Created an attachment (id=13572)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13572&action=view)
the assembly (.s) file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31977
Dear all
It looks like specifying the option -x f77-cpp-input forces the preprocessor to
be run even though the input files are object or static libraries.
As an toy exmple try with a simple prog.f
% gfortran -x f77-cpp-input -c prog.f
% gfortran -x f77-cpp-input prog.o -o prog
It looks like the
--- Comment #1 from bmcfadden at cdp dot com 2007-05-17 16:48 ---
Created an attachment (id=13571)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13571&action=view)
The file from -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31977
I'm using gcc 3.4.5, and I was looking into a weird condition. The following
program compiles OK:
#include
int alloc()
{
return 0;
}
int main(int argc, char* argv[])
{
printf("Testing!\n");
if(alloc() == 0)goto Radhe;
return 0;
Radhe:
printf("Hello\n");
}
The resul
--- Comment #7 from andrew dot stubbs at st dot com 2007-05-17 16:37
---
Another example that might be of interest if anybody eventually tries to fix
this:
void
foo ()
{
for (int i = 0; int i = 0; i++) ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2288
I'm getting the following ICE with gcc 4.3 20060515 and -O3:
(sid)24074:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O3
838.c
838.c: In function 'rPIc_entry':
838.c:3181: internal compiler error: in ssa_operand_alloc, at
tree-ssa-operands.c:487
Please submit a full bug report
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:17
---
Nothing platform-specific.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
GC
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:15
---
Configure using an absolute path as recommended in the build instructions.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:13
---
*** This bug has been marked as a duplicate of 27935 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:13
---
*** Bug 29045 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 16:10
---
Fixed in 4.1.x and later.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-05-17 16:05 ---
Works for me. What OS are you using and where did you get
the version of gfortran? An illegal instruction error
normally means you are using a version of gfortran on the
wrong architecture (ie., i686 on amd64).
--
--- Comment #4 from tbm at cyrius dot com 2007-05-17 15:58 ---
(In reply to comment #3)
> Is this still a problem? I don't see it in the logs.
Seems to work fine here now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30815
--- Comment #2 from bangerth at dealii dot org 2007-05-17 15:55 ---
Initializer syntax
int i = i;
is a gcc extension. You may want to read the documentation of -Winit-self.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:53
---
2006-10-03 Eric Botcazou <[EMAIL PROTECTED]>
* builtins.c (expand_builtin_return_addr): Deal with FRAME_ADDR_RTX.
* doc/tm.texi (Basic Stack Layout): Document FRAME_ADDR_RTX.
* config/sp
--- Comment #3 from bangerth at dealii dot org 2007-05-17 15:53 ---
I agree as well.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from bangerth at dealii dot org 2007-05-17 15:51 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:50
---
*** Bug 27901 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:50
---
*** This bug has been marked as a duplicate of 31523 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from bangerth at dealii dot org 2007-05-17 15:48 ---
Indeed, like Andrew says.
--
bangerth at dealii dot org changed:
What|Removed |Added
Statu
--- Comment #1 from bangerth at dealii dot org 2007-05-17 15:46 ---
The link you give doesn't work. Can you attach your testcase?
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:36
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-17 15:34
---
Another example perhaps?
void
foo()
{
try
{
}
catch (void *e)
{
void *e; // invalid
}
}
The C++ standard, clause 3.3.2 paragraph 3, states that catch
exception-declarations may not be re
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:34
---
Do you still have the testcase?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:30
---
Not a GCC bug.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:29
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:28
---
3.3.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from tbm at cyrius dot com 2007-05-17 15:20 ---
Created an attachment (id=13570)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13570&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:17
---
3.4.x is not maintained anymore.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
I'm getting a bootstrap error on mips with 4.3 SVN 20070515 revision 124745.
The compiler segfaults when compiling libstdc++-v3/src/strstream.cc with:
Program received signal SIGSEGV, Segmentation fault.
0x0074701c in try_split (pat=, trial=0x2bfb31e0, last=1)
at ../../src/gcc/emit-rtl.c:3286
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-17 15:11
---
Is this still a problem? I don't see it in the logs.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from hjl at lucon dot org 2007-05-17 15:06 ---
Failures look like
Fortran runtime error: Attempt to allocate a negative amount of memory.
FAIL: libgomp.fortran/vla1.f90 -O2 execution test
Is this related to
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00148.html
--
In
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00804.html
there are
FAIL: libgomp.fortran/vla1.f90 -O2 execution test
FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer execution test
FAIL: libgomp.fortran/vla1.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: libg
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:52
---
Definitively closed on the 4.0 and 4.1 branches, it's too late for caring about
ICE-on-invalid there at this point.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:44
---
Won't be fixed on the 4.0 and 4.1 branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:43
---
Confirmed by Richard.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from tkoenig at gcc dot gnu dot org 2007-05-17 14:40
---
Created an attachment (id=13569)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13569&action=view)
partial implementation
Here's a partial implementation that seems to get
things right for the (min)|(max)loc0
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-05-17 14:34
---
Fixed on all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/combine.c
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/combine.c
ombine.c (simplify_set): Build a new src pattern instead of
substituting its operands in the COMPARE case.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20070517-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/
1 - 100 of 122 matches
Mail list logo
