--- Comment #117 from pinskia at gcc dot gnu dot org 2007-06-22 07:24
---
(In reply to comment #116)
> There is currently a new ICE
If you can reproduce it still, please CC me on the bug (as I caused this bug).
I might already have a fix for this bug already too (though the trip to Ja
--prefix=/scratch/vondele/gcc_trunk/build
--with-mpfr_include=/scratch/vondele/mpfr-2.2.0/
--with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/
--enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20070622 (experimental)
The source can be obtained as explained in co
--- Comment #118 from jv244 at cam dot ac dot uk 2007-06-22 07:34 ---
(In reply to comment #117)
> (In reply to comment #116)
> > There is currently a new ICE
>
> If you can reproduce it still, please CC me on the bug (as I caused this
> bug).
> I might already have a fix for this bug
--- Comment #6 from spop at gcc dot gnu dot org 2007-06-22 07:52 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
It is not the vectorizer that is in fault here: applying my patch does
not impact the output of -fdump-tree-vect-all-all except fo
--- Comment #7 from spop at gcc dot gnu dot org 2007-06-22 08:09 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
I fail to see what changes. Both before and after applying my patch
the assembly diff is the same. I cannot reproduce the bug on
--- Comment #4 from daney at gcc dot gnu dot org 2007-06-22 08:38 ---
Looking at the rtl dumps of unwind-dw2.c compiled with -O1 I find:
In unwind-dw2.c.135r.subreg (_Unwind_Resume):
.
.
.
(insn 72 71 73 6 ../../../trunk/libgcc/../gcc/unwind.inc:216 (parallel [
(unspec [
--- Comment #6 from spop at gcc dot gnu dot org 2007-06-22 08:40 ---
I cannot reproduce the ICE on trunk at 125915, on i686-linux
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from spop at gcc dot gnu dot org 2007-06-22 08:49 ---
I cannot reproduce this bug on trunk rev.125915, on i686-linux.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from spop at gcc dot gnu dot org 2007-06-22 08:53 ---
I cannot reproduce the ICE on trunk at 125915, and i686-linux.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
gfortran accepts this code while INTEL and SUN compilers reject it:
$> cat private.f90
MODULE foomod
TYPE :: footype
PRIVATE
integer :: dummy
END TYPE
END MODULE
PROGRAM foo_test
USE foomod
TYPE(footype) :: foo
foo = footype(1)
END
$> sunf95 -w4 private.f90
foo = footype(1)
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-06-22 09:11
---
I'm not surprised that converting it to an unspec_volatile stops
us from deleting the instruction, but that wasn't really my concern.
As I said earlier, several other ports use top-level unspecs (rather than
unspe
--- Comment #7 from rob1weld at aol dot com 2007-06-22 09:18 ---
Uros Bizjak - has to include warnings about not drying animals in it
I have an older model with no such label therefore I am OK. ;)
--- Here is another program that demonstrates that there is some problem ---
/*
>>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-22 09:24 ---
Can you provide a backtrace?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32459
--- Comment #23 from burnus at gcc dot gnu dot org 2007-06-22 09:41 ---
> All Used Variables intialized
Do you actually get still wrong results with gfortran? If yes, which platform
and compiler version?
Here, I fail to get a wrong result with ifort, NAG f95, sunf95, gfortran 4.1.3,
4.2
--- Comment #2 from ubizjak at gmail dot com 2007-06-22 09:50 ---
The problem here is exposed with core2_cost table, where mmxsse_to_integer is
as low (2 units) as move between integer registers (2 units). Such a low value
causes gcc to happily move SImode values between SSE and integer
--- Comment #10 from sebpop at gmail dot com 2007-06-22 10:12 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Grrr, I mean, I will test the patch now on amd64 ;-)
On 6/22/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> Okay, I'm testing that o
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-22 10:13 ---
(In reply to comment #1)
> Can you provide a backtrace?
>
1 compute_screening_matrices
Breakpoint 1, internal_error (gmsgid=0xae1dff "in %s, at %s:%d")
at /scratch/vondele/gcc_trunk/gcc/gcc/diagnostic.c:596
596
--- Comment #9 from spop at gcc dot gnu dot org 2007-06-22 10:11 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Okay, I'm testing that on an amd64 machine. Sorry for the confusion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
--- Comment #8 from rob1weld at aol dot com 2007-06-22 09:42 ---
A earlier version of this program had these lines in it:
...
f = abs((float)(a));
g = fabs((float)(a));
h = (int)abs(a);
i = 0.0;
printf("a = %.2f b = %.2f c = %.2f d = %.2f e = %.2f ", a, b, c,
--- Comment #13 from hubicka at ucw dot cz 2007-06-22 09:36 ---
Subject: Re: [4.3 Regression] cannot take address of bit field
> After you solve that there is that little matter of udivdi3.
udivdi3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
--- Comment #8 from ubizjak at gmail dot com 2007-06-22 09:36 ---
(In reply to comment #7)
> I fail to see what changes. Both before and after applying my patch
> the assembly diff is the same. I cannot reproduce the bug on
> i686-linux.
This bug can be reproduced only on x86_64 host
--- Comment #12 from hubicka at ucw dot cz 2007-06-22 09:35 ---
Subject: Re: [4.3 Regression] cannot take address of bit field
Hi,
I've experimented with this a bit - the problem is that the error is
produced during gimplification: gimplifier translates the expression
into the addr_exp
--- Comment #14 from rguenther at suse dot de 2007-06-22 09:45 ---
Subject: Re: [4.3 Regression] cannot take address of
bit field
On Fri, 22 Jun 2007, hubicka at ucw dot cz wrote:
> --- Comment #12 from hubicka at ucw dot cz 2007-06-22 09:35 ---
> Subject: Re: [4.3 Regressi
--- Comment #2 from charlet at gcc dot gnu dot org 2007-06-22 10:43 ---
This now compiles cleanly on trunk.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from charlet at gcc dot gnu dot org 2007-06-22 10:44 ---
This now generates a proper error on trunk.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from jakub at gcc dot gnu dot org 2007-06-22 12:17 ---
Subject: Bug 17002
Author: jakub
Date: Fri Jun 22 12:17:00 2007
New Revision: 125946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125946
Log:
2007-02-24 Jakub Jelinek <[EMAIL PROTECTED]>
libjava/classpath
--- Comment #9 from ubizjak at gmail dot com 2007-06-22 12:26 ---
(In reply to comment #8)
> I'll work on some debugging and see if I can find out how it derives the value
> of "i" that it prints differently each time.
Don't worry, it works correctly.
The non-problem you are going aft
--- Comment #3 from ubizjak at gmail dot com 2007-06-22 12:02 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01615.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from tbm at cyrius dot com 2007-06-22 12:56 ---
This bug is extremely common (seen while compiling the Debian archive).
Honza, can you take a look soon?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563
--- Comment #15 from malitzke at metronets dot com 2007-06-22 12:51 ---
> > After you solve that there is that little matter of udivdi3.
> udivdi3?
In comment 7 somebody (dcb) remarked about PR31654 (marked duplicate to this
bug) was impeding kernel compilation. In comment 10 it was rei
--- Comment #2 from pault at gcc dot gnu dot org 2007-06-22 13:03 ---
This fixes it:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (révision 125706)
+++ gcc/fortran/resolve.c (copie de travail)
@@ -
--- Comment #24 from burnus at gcc dot gnu dot org 2007-06-22 13:26 ---
Additional note - as pointed out by Ian of NAG:
program main
implicit none
integer :: jt, it(100)
real:: tt
equivalence(jt,tt)
do i=1,100
tt=i
it(i)=jt
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 13:15 ---
(In reply to comment #3)
> Dump a valid program which contains equivalence to show a harder case for the
> checks (NAG f95 chokes on it).
Actually this is wrong according to the Section 16.5.6 of the F2003 standard:
"
--- Comment #26 from burnus at gcc dot gnu dot org 2007-06-22 14:32 ---
(In reply to comment #25)
> I was tracking what appeared to be the similar bugs in gfortran and g95, but
> some where in the last few steps when I could not test with gfortran - I lost
> the gfortran link.
You are l
--- Comment #25 from dir at lanl dot gov 2007-06-22 14:28 ---
I was tracking what appeared to be the similar bugs in gfortran and g95, but
some where in the last few steps when I could not test with gfortran - I lost
the gfortran link.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
svn revision 125948
$ gcc -mno-cygwin -O4 bit_allocate.c -save-temps
bit_allocate.c: In function 'a52_bit_allocate':
bit_allocate.c:127: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instru
--- Comment #1 from jojelino at gmail dot com 2007-06-22 16:01 ---
Created an attachment (id=13762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13762&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
--- Comment #2 from jojelino at gmail dot com 2007-06-22 16:06 ---
fails if given -Olevel level>2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32461
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 fails to link libgcj.so:
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: relocation must bind locally
collect2: ld returned 1 exit status
make[3]
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:21
---
Subject: Bug 32360
Author: jvdelisle
Date: Fri Jun 22 16:21:23 2007
New Revision: 125949
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125949
Log:
2007-06-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:25
---
Fixed on trunk (4.3) closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from dje at watson dot ibm dot com 2007-06-22 16:44 ---
Subject: Re: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
There are much more constructive ways in which to interact with
the GCC community, GCC developers, and port maintainers than you have
chosen to pursue.
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-22 16:24
---
Subject: Bug 32360
Author: jvdelisle
Date: Fri Jun 22 16:23:55 2007
New Revision: 125950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125950
Log:
2007-06-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from anlauf at gmx dot de 2007-06-22 17:33 ---
Created an attachment (id=13763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13763&action=view)
Demo code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
--- Comment #2 from alan dot hardin at paulsson dot com 2007-06-22 17:36
---
The attached code fails if compiled with any optimization. I am trying to use
<<= operation to calculate the valid range of a bitfield.
--
alan dot hardin at paulsson dot com changed:
What|
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 and my patch to support boehm-gc for x86-64
http://gcc.gnu.org/ml/java-patches/2007-q2/msg00330.html
fails when linking the 64-bit libgcj:
[ca. 6800 lines omitted]
gnu::gcj::runtime::FinalizerThread::finalizer_
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-22 17:51 ---
Subject: Bug 32413
Author: uros
Date: Fri Jun 22 17:51:06 2007
New Revision: 125951
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125951
Log:
PR target/32413
* config/i386/i386.c (ix86_register_move_co
--- Comment #7 from bergner at gcc dot gnu dot org 2007-06-22 17:56 ---
Subject: Bug 26026
Author: bergner
Date: Fri Jun 22 17:56:14 2007
New Revision: 125952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125952
Log:
Reassociation rewrite backport from mainline.
2006-0
--
Summary: [4.0.2
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alan dot hardin at pau
Hi,
the attached code started to ICE with gfortran 4.3.0 shortly
after 20070416:
% gfortran -c gfcbug64.f90
gfcbug64.f90:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--- Comment #1 from alan dot hardin at paulsson dot com 2007-06-22 17:33
---
Created an attachment (id=13764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13764&action=view)
Test code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32463
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-22 18:15
---
Herald,
Both cases work for me on latest trunk. x86-64 I tried several compiler
switches as well, no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32464
--- Comment #7 from vapier at gentoo dot org 2007-06-22 18:17 ---
the testcase was distilled by Harald van Dijk <[EMAIL PROTECTED]>, not myself
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32389
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-22 18:17 ---
I can only partially reproduce this: I don't get a crash, but valgrind shows:
==12017== Conditional jump or move depends on uninitialised value(s)
==12017==at 0x45229B: gfc_resolve_expr (resolve.c:3272)
==12017==
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-22 18:26 ---
Reduced testcase and backtrace:
module gfcbug64_mod1
contains
function copy (d)
real, intent(in) :: d(:)
real :: copy(size (d))
copy = d
end function copy
end module gfcbug64_mod1
module
--- Comment #2 from hjl at lucon dot org 2007-06-22 18:26 ---
On Linux, I got
02e1b960 1 OBJECT LOCAL HIDDEN 25
gnu::gcj::runtime::FinalizerThread::finalizer_ready
It looks like assembler/linker on Solaris don't have proper visibility
support.
BTW, the last symbol visi
--- Comment #3 from ubizjak at gmail dot com 2007-06-22 18:29 ---
The testcase:
--cut here--
typedef struct
{
unsigned char exp[256];
}
expbap_t;
void
a52_bit_allocate (expbap_t * expbap)
{
int i;
unsigned char *exp;
exp = expbap->exp;
int lowcomp;
do
{
if (exp[i
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-22 18:33 ---
Subject: Bug 31473
Author: dfranke
Date: Fri Jun 22 18:33:35 2007
New Revision: 125954
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125954
Log:
2007-06-22 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #5 from burnus at gcc dot gnu dot org 2007-06-22 18:34 ---
Regression testing shows that it was introduced between
2007-05-11-r124613 and 2007-05-12-r124634.
There were two Fortran patches checked in during that period:
http://gcc.gnu.org/viewcvs?view=rev&revision=124613
r1
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-22 18:34 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-06-22 18:38 ---
> r124633 | pault | 2007-05-12 08:19:43 +0200 (Sat, 12 May 2007) | 15 lines
> 2007-05-12 Paul Thomas <[EMAIL PROTECTED]>
>PR fortran/30746 (resolve.c, match.h, gfortran.h)
The assert is triggered in check
--- Comment #2 from patchapp at dberlin dot org 2007-06-22 18:50 ---
Subject: Bug number PR20888
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01656.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #8 from uros at gcc dot gnu dot org 2007-06-22 18:51 ---
Subject: Bug 32374
Author: uros
Date: Fri Jun 22 18:51:28 2007
New Revision: 125955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125955
Log:
PR middle-end/32374
* expr.c (store_constructor): D
--- Comment #11 from burnus at gcc dot gnu dot org 2007-06-22 18:51 ---
> Grrr, I mean, I will test the patch now on amd64 ;-)
Do you still need the stuff mentioned in comment #7 or not? I would guess not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32457
--- Comment #5 from ubizjak at gmail dot com 2007-06-22 18:55 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #9 from ubizjak at gmail dot com 2007-06-22 18:55 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
#include
void __attribute__ ((__noinline__))
add14(unsigned short int nextID)
{
struct {
unsigned short int id: 14;
} hdr;
hdr.id = nextID;
do {
hdr.id++;
if (printf ("should print 0x: 0x%04X\n", (unsigned int)hdr.id))
break;
} while (1);
}
main()
{
add14 (0x3FFF)
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-22 19:16 ---
One of the problems is that
gfc_match_rvalue (&expr);
does not set expr to NULL by default or when an error occurs. Therefore
gcc_assert (expr && sym == expr->symtree->n.sym);
does not fail but crashes randomly.
Description:
This negative test case was derived from OpenMP test omp1/F2_6_1_5a.f90. On
p. 85 of the OpenMP API Version 2.5 May 2005 line 22 states:
"* Allocatable arrays may not appear in a copyin clause."
The structure struct1 is made up of an allocatable array a. The structure
appears in a
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-22 19:48 ---
Then it's a dup of PR32417.
*** This bug has been marked as a duplicate of 32417 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-22 19:48 ---
*** Bug 32459 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24965
Description:
This test case exhibits the problem that the presence of a SECTIONS directive
with only one SECTION inside of a PARALLEL region causes only one thread to be
created when omp_set_num_threads was previously called with 4 threads. If
the directives internal to this PARALLEL region are co
--- Comment #8 from burnus at gcc dot gnu dot org 2007-06-22 20:04 ---
> One probably should fix gfc_match_rvalue rather than using simply expr = NULL
> in check_host_association.
At least setting result = NULL at the top of gfc_match_rvalue is wrong. (I
don't know whether a single tes
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-06-22 20:20
---
Keeping track of these here.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from spop at gcc dot gnu dot org 2007-06-22 20:20 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
> Do you still need the stuff mentioned in comment #7 or not? I would guess not.
>
No, I'm debugging that on an amd64. Thanks.
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-22 20:28 ---
Reduced testcase:
$> cat pr32467.f90
use omp_lib
integer, save, allocatable :: a(:)
!$omp threadprivate(a)
allocate(a(2))
a = 1
!$omp parallel copyin(a)
print *, a(1)
!$omp end parallel
deallocate(a)
end
This code
--- Comment #1 from tiberius1 at gmx dot li 2007-06-22 20:35 ---
The GNAT bug box is not showing up in SVN snapshot gcc-4.3-20070615 (configured
with the same options as above)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32442
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-22 20:38 ---
Barf. The testcase in comment #1 is detected by gfortran-svn (20070522), the
original testcase (allocatable structure components) is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-22 20:42 ---
Mine. Fix should be easy :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 21:06 ---
Thanks for the report.
(By the way, ifort does accept the program and gives the right result whereas
sunf95 has the same problem as gfortran.)
There are actually two problems:
a) "Allocatable arrays may not appear
5 sections will
result in 4 threads as NT==4.
This is true for both, 4.2 and latest svn (20070622).
Adding Jakub as CC.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-06-22 21:54 ---
There are several issues, will fix them on Monday.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-06-22 22:16 ---
Created an attachment (id=13765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13765&action=view)
proposed patch
This fixes the test case. It'll be a while before I
can regression-test and submit this, becaus
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-22 22:29 ---
The tree level looks exactly the same between C and C++ front-ends while the
C++ front-end gets the wrong code for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
every invocation of gcc fails with such error:
$ i386-mingw32-gcc hello_c.c -c -v
Using built-in specs.
Target: i386-mingw32
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --bindir=/usr/i386-mingw32/bin --libdir=/usr/lib64
--libexecdir=/usr/lib64 --in
--- Comment #1 from pluto at agmk dot net 2007-06-22 23:13 ---
stat("/usr/bin/../../lib64/gcc/i386-mingw32/4.3.0/cc1", 0x7fff0e91cb00) = -1
ENOENT (No such file or directory)
stat("/usr/bin/../../lib64/gcc/cc1", 0x7fff0e91cb00) = -1 ENOENT (No such file
or directory)
stat("/usr/bin/../..
--- Comment #16 from hubicka at ucw dot cz 2007-06-22 23:59 ---
Subject: Re: [4.3 Regression] cannot take address of bit field
>
> Yes. It looks like a frontend bug if the tree was not marked addressable
> before gimplification but would need to after.
This does not seem to be so ea
--- Comment #8 from hubicka at ucw dot cz 2007-06-23 00:00 ---
Subject: Re: [4.3 Regression] ice for legal code with flags -O2
-fno-unit-at-a-time
> This bug is extremely common (seen while compiling the Debian archive).
> Honza, can you take a look soon?
I will check it tomorrow. Ho
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-23
01:57 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
The same failures occur on hppa-unknown-linux-gnu.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
--- Comment #7 from zadeck at naturalbridge dot com 2007-06-23 02:12
---
dave,
i have a patch for this. i am doing regtests now and will have a patch posted
first thing tomorrow.
the bug is in dce.c:deletable_insn_p. The problem is that it does not look
inside of parallels. so eve
--- Comment #10 from patchapp at dberlin dot org 2007-06-23 03:05 ---
Subject: Bug number PR32446
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01683.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-23 03:13
---
This problem is frontend related. We are building the switch case that tests
for the error conditions outside the loop that is constructed to do the scaler
transfers. Thus:
i = 1;
if
Compiling the following code with fvisibility=hidden exports Test::test().
(The used compiler is 4.2.1 20070622. Version 4.2.0 on a i686 gives the same
results).
~$ cat test.cc
#include
class Test
{
void test();
};
void Test::test() { }
~$ g++ -fvisibility=hidden -fPIC -c -o test.o test.cc
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-23 03:58
---
Fairly straight forward I think.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from rob1weld at aol dot com 2007-06-23 04:21 ---
(In reply to comment #9)
> Don't worry, it works correctly.
> ...
> Argument are pushed to the stack by the caller without any other
> communication with callee, so it is obvious that format string _must_
> reflect the ty
--
rob1weld at aol dot com changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32448
--- Comment #11 from kargl at gcc dot gnu dot org 2007-06-23 05:06 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Don't worry, it works correctly.
> > ...
> > Argument are pushed to the stack by the caller without any other
> > communication with callee, so it is obvious th
98 matches
Mail list logo
