--- Comment #5 from ghazi at gcc dot gnu dot org 2008-09-12 07:06 ---
(In reply to comment #4)
Yes, your right it is a bug in Sun's Compiler. For those interested it is bug
ID: 6406892. The sun patch that fixes this bug is 121015-06 available here:
--- Comment #13 from hubicka at gcc dot gnu dot org 2008-09-12 08:33
---
Having testcase would be great. In theory removing unused things from debug
info should not make any difference. Perhaps it is related to stack frame
packing, that is only other place walking blocks.
could you
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-09-12 08:39
---
Created an attachment (id=16301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16301action=view)
patch that should fix the sixtrack problem.
This patch should solve the sixtrack problem. Can you please test
--- Comment #2 from singler at gcc dot gnu dot org 2008-09-12 08:45 ---
Clearly, this is a potential conflict, and the solution is pretty obvious.
However, I am unable to reproduce it on x86_64-unknown-linux-gnu, for a
definite test case. Do you have a simple testcase that triggers
--- Comment #32 from lthode at mail dot unomaha dot edu 2008-09-12 10:36
---
For all Gentoo users who are hitting this bug:
Update your GLibC to 2.7r2 or later, the new versions do not use multilib
wrappers any longer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-09-12 09:52 ---
Testing patch..
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #9 from erik dot moller at cycos dot com 2008-09-12 11:33
---
true, -fno-strict-aliasing makes even -O3 work... I don't know about the
liasing, the example is very simple, can that happen when the SSE2 intrinsics
are involved?
--
--- Comment #15 from drow at gcc dot gnu dot org 2008-09-12 12:43 ---
Reopening...
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from drow at gcc dot gnu dot org 2008-09-12 12:43 ---
Fixed.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
Compiling the following with -O0 works. Compiling with -O2 produces assembly
syntax errors.
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.1
--- Comment #2 from grosser at gcc dot gnu dot org 2008-09-12 12:55 ---
Created an attachment (id=16302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16302action=view)
Just a simple loop over an array
I can confirm this one using this simple test case.
--
Hi,
While using GCC 4.3.1, I observed that the specialized inline
code is generated automatically which causes problem in the following
case.
-
/* File name: t.c */
static int
WaitLoop (unsigned int
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-12 13:40 ---
Mine.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #1 from graham dot stott at btinternet dot com 2008-09-12
14:04 ---
Subject: Re: New: Auto inline when optimisation is enabled, causes problem.
All,
Read the documentation for %= w.r.t generating unique labels inline
assembler.
Replacing your uses of _loop with _loop%=
--- Comment #1 from ubizjak at gmail dot com 2008-09-12 14:13 ---
(In reply to comment #0)
asm(
xorl %1, %1\n
movl $0x12345678, %0\n
bsrl %2, %0 ; setz %b1
: =r (res), =r (resz)
: g (val)
Use q constraint for operand 1. You will also need earlyclobbers on output
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-12 14:21 ---
Try
static int
WaitLoop (unsigned int count)
{
asm (1: tst %0, %0\n bf/s 1b\n add #-1, %0: =r
(count):0 (count));
return count;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37493
--- Comment #2 from zeev dot tarantov at gmail dot com 2008-09-12 14:24
---
Thank you so much and sorry for the spam in bugzilla. Is there anything like
lint that would have helped me understand the mistake, without actually
grokking the documentation?
--
--- Comment #10 from jakub at gcc dot gnu dot org 2008-09-12 14:26 ---
*** This bug has been marked as a duplicate of 37483 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-12 14:26 ---
*** Bug 37395 has been marked as a duplicate of this bug. ***
--
Bug 37483 depends on bug 37395, which changed state.
Bug 37395 Summary: [4.4 Regression] Bootstrap fails in stage 2 due to segfault
compiling
The function 'fonc' defined in the module below is not recognized by the
subroutine 'sub' in the same module.
module essai
!---
contains
!---
subroutine sub ()
implicit none
double precision :: fonc
double precision :: d
d = fonc()
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-12 14:47 ---
Removing the
double precision :: fonc
from sub makes the program compile as expected (as I guess). I'm not sure if
that's a bug or a problem with the original code, but I could imagine that this
declaration makes
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-12 14:53 ---
Works with gfortran 4.2.3, but not with 4.3.2 nor 4.4.0 (trunk).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37494
On i686-apple-darwin9, gcc.c-torture/compile/vector-4.c fails with:
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:19:no such
instruction: `vmovq (%eax), %xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:20:no such
instruction: `vmovq %xmm0, -48(%ebp)'
There are no specific tests for following SSE intrinsics:
xmmintrin.h
_mm_extract_pi16
_mm_insert_pi16
_mm_shuffle_pi16
_mm_prefetch
_mm_cmpeq_ss
_mm_cmplt_ss
_mm_cmple_ss
_mm_cmpgt_ss
_mm_cmpge_ss
_mm_cmpneq_ss
_mm_cmpnlt_ss
_mm_cmpnle_ss
_mm_cmpngt_ss
_mm_cmpnge_ss
_mm_cmpord_ss
--- Comment #3 from prafullat at kpitcummins dot com 2008-09-12 15:18
---
Thank you HJ.
This works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37493
--- Comment #3 from Jean-Charles dot Gilbert at inria dot fr 2008-09-12
15:26 ---
(In reply to comment #1)
Removing the
double precision :: fonc
from sub makes the program compile as expected (as I guess). I'm not sure if
that's a bug or a problem with the original code, but I
--
hjagasia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hjagasia at gcc dot gnu dot
|dot org
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-09-12 15:44
---
Jan and I have a bug fix for this, which will be posted in some time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
--- Comment #8 from nickc at redhat dot com 2008-09-12 15:52 ---
Created an attachment (id=16303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16303action=view)
Implement alignment for non-local commons
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
--- Comment #9 from nickc at redhat dot com 2008-09-12 15:54 ---
Hi Brian,
Please could you try out the uploaded patch which is an implementation of
your idea to add an extra alignment directive when emitting commons. It seems
to work for the test case you gave, but I have not yet
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-12 15:56 ---
(In reply to comment #3)
(In reply to comment #1)
Removing the
double precision :: fonc
from sub makes the program compile as expected (as I guess). I'm not sure
if
that's a bug or a problem with
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-12 16:11 ---
... I'm not sure if your code is still valid Fortran and this a bug. I'm not
the right one to judge here.
I am not the right one either and I did not find anything in the standard to
support the following:
It
When I try to compile a openMP fortran code, the following error message
occurs:
1230: internal compiler error: Segmentation fault
I can compile the code correct using Intel fortran compiler. Could anybody give
me instructions on what might be the problem?
Thanks a lot!
--
--- Comment #6 from Jean-Charles dot Gilbert at inria dot fr 2008-09-12
16:21 ---
(In reply to comment #5)
... I'm not sure if your code is still valid Fortran and this a bug. I'm
not the right one to judge here.
I am not the right one either and I did not find anything in the
--- Comment #1 from aesok at gcc dot gnu dot org 2008-09-12 16:46 ---
Subject: Bug 37466
Author: aesok
Date: Fri Sep 12 16:45:34 2008
New Revision: 140321
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140321
Log:
PR target/37466
* config/avr/avr.md
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-12 16:52 ---
(In reply to comment #0)
I can compile the code correct using Intel fortran compiler. Could anybody
give
me instructions on what might be the problem?
No.
You did not
1) tell us what version of gfortran you
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-09-12 16:52
---
The reduced test case block-2.c triggers 3 seperate bugs.
First:
In tranlate_clast when clast stmt is a stmt_user, we can end up disconnecting
the edge that is the exit_edge of the scop that is transformed. This
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-09-12 16:54
---
Created an attachment (id=16304)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16304action=view)
This patch fixes all three problems in the reduced test case block-2.c
--
GNU Fortran (GCC) 4.3.3 20080904 (prerelease)
FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE, amd64
Given the program:
ROGRAM test_kind
IMPLICIT NONE
INTEGER :: i, j
INTEGER, DIMENSION(1:3) :: kind_numbers
kind_numbers(1:3) = 3
DO i = 1, 3
j = kind_numbers(i)
PRINT*,i,j
ENDDO
END PROGRAM
--- Comment #6 from hjagasia at gcc dot gnu dot org 2008-09-12 16:59
---
2008-09-05 Jan Sjodin [EMAIL PROTECTED]
Harsha Jagasia [EMAIL PROTECTED]
* graphite.c (gmp_cst_to_tree): Moved.
(iv_stack_entry_is_constant): New.
(iv_stack_entry_is_iv):
--- Comment #2 from aesok at gcc dot gnu dot org 2008-09-12 17:30 ---
Subject: Bug 37466
Author: aesok
Date: Fri Sep 12 17:29:38 2008
New Revision: 140323
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140323
Log:
PR target/37466
* config/avr/avr.md
--- Comment #3 from aesok at gcc dot gnu dot org 2008-09-12 17:36 ---
Fixed.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
I'm testing gcc on the file all.i.gz in PR26854, configured as
Configured with: ../../mainline/configure --enable-checking=release
--with-gmp=/pkgs/gmp-4.2.2/ --with-mpfr=/pkgs/gmp-4.2.2/
--prefix=/pkgs/gcc-mainline --enable-languages=c
--enable-gather-detailed-mem-stats
and compiled with
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-12 17:43
---
Created an attachment (id=16305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16305action=view)
Mainline memory and time stats from July 29
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37499
--- Comment #2 from lucier at math dot purdue dot edu 2008-09-12 17:44
---
Created an attachment (id=16306)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16306action=view)
Mainline time and memory stats for revision 140295, 09/11/2008
--
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-12 17:53 ---
We can't define FLOAT_STORE_FLAG_VALUE for SSE since we can't
represent 0xfff as a valid FP value. This patch makes
fold_rtx to match simplify_relational_operation:
--- ./cse.c.foo 2008-09-08 10:46:09.0
--- Comment #1 from jv244 at cam dot ac dot uk 2008-09-12 17:56 ---
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
--- Comment #7 from jv244 at cam dot ac dot uk 2008-09-12 18:02 ---
(In reply to comment #5)
It seems that declaring 'fonc' makes it external to the module, while without
any declaration, 'fonc' is found to be the internal procedure defined within
the module.
which is the correct
--- Comment #10 from ubizjak at gmail dot com 2008-09-12 18:03 ---
This is in fact undefined code. When Transform4x4() gets inlined in fun(), you
are accessing pAR[0] (aliased to *pMatrix) as short and as __m128i. Since
-fstrict-aliasing (the default) assumes that short can't alias
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-12 18:07 ---
I've not checked, but maybe this is related to PR 37199?
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/x86-64, libstdc++ failed to compile at -O0:
[EMAIL PROTECTED] gcc-work]$
/export/build/gnu/gcc-work/build-x86_64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc-work/build-x86_64-linux/./gcc
-nostdinc++
--- Comment #2 from kargl at gcc dot gnu dot org 2008-09-12 18:30 ---
(In reply to comment #1)
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
Why is it nonstandard?
Maybe I'm misreading 5.5.2.1 and 5.5.2.3 from the F95 standard, which
suggest
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-12 18:43 ---
Can you add
/* { dg-do compile } */
to gcc.c-torture/compile/vector-4.c?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37495
--- Comment #3 from kargl at gcc dot gnu dot org 2008-09-12 18:44 ---
(In reply to comment #2)
(In reply to comment #1)
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
Why is it nonstandard?
Maybe I'm misreading 5.5.2.1 and 5.5.2.3 from
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2008-09-12
18:47 ---
Subject: Re: [4.4 regression] dwarf2 unwind info patches produce undefined
symbols
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00978.html
--
--- Comment #4 from jv244 at cam dot ac dot uk 2008-09-12 18:48 ---
(In reply to comment #2)
(In reply to comment #1)
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
Why is it nonstandard?
Maybe not, I was guessing based on 16.5.6 that
--- Comment #2 from jv244 at cam dot ac dot uk 2008-09-12 18:50 ---
(In reply to comment #1)
I've not checked, but maybe this is related to PR 37199?
I can not reproduce that with the 4.3 branch:
gcc version 4.3.3 20080912 (prerelease) (GCC)
[EMAIL PROTECTED]:/data03/vondele/bug
--- Comment #5 from raksit at gcc dot gnu dot org 2008-09-12 18:52 ---
Created an attachment (id=16307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16307action=view)
new test: gcc/testsuite/g++.dg/opt/cse3.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37489
--- Comment #6 from raksit at gcc dot gnu dot org 2008-09-12 18:54 ---
(In reply to comment #4)
We can't define FLOAT_STORE_FLAG_VALUE for SSE since we can't
represent 0xfff as a valid FP value. This patch makes
fold_rtx to match simplify_relational_operation:
--- ./cse.c.foo
--- Comment #5 from kargl at gcc dot gnu dot org 2008-09-12 19:03 ---
(In reply to comment #4)
(In reply to comment #2)
(In reply to comment #1)
the program is non-standard Fortran, but it is legacy, so an option would
be
useful.
Why is it nonstandard?
Maybe
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-09-12 19:05 ---
This may be due to an incompatibility between the 4.3
and 4.4 libraries.
What result do you get when you compile with -static,
to make sure that you get the right library?
--
$ cat 43.f90
end
$ cat 44.f90
end
$ gfortran-4.3 -fdump-tree-original 43.f90
$ gfortran -fdump-tree-original 44.f90
$ diff -u *original
--- 43.f90.003t.original2008-09-12 21:12:50.0 +0200
+++ 44.f90.003t.original2008-09-12 21:12:59.0 +0200
@@ -1,8 +1,8 @@
MAIN__ ()
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-09-12 19:19 ---
See PR 37501.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-12 19:32 ---
Subject: Re: FAIL: gcc.c-torture/compile/vector-4.c
Can you add
/* { dg-do compile } */
to gcc.c-torture/compile/vector-4.c?
Yes, indeed I can, but will this work better than
[ibook-dhum] f90/bug% gcc44 -c
--- Comment #5 from brtnfld at hdfgroup dot org 2008-09-12 19:38 ---
(In reply to comment #3)
This may be due to an incompatibility between the 4.3
and 4.4 libraries.
What result do you get when you compile with -static,
to make sure that you get the right library?
That fixed
--- Comment #7 from hjl dot tools at gmail dot com 2008-09-12 19:40 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00984.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-12 19:42 ---
It is caused by revision 140285.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-09-12 19:47 ---
(In reply to comment #5)
(In reply to comment #3)
This may be due to an incompatibility between the 4.3
and 4.4 libraries.
What result do you get when you compile with -static,
to make sure that you get
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37501
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-09-12 19:57 ---
The value of i gets overwritten in the library when assiging
a value to dtp-u.p.mode. OUCH.
This is what I get when running the 4.3 - compiled program
against the 4.4 library:
$ gfortran-4.3 -g foo.f90
$ gdb
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-09-12 19:59
---
Fixed by
2008-09-11 Jeff Law [EMAIL PROTECTED]
* reload1.c (alter_reg): Undo the BYTE_BIG_ENDIAN correction performed
by assign_stack_local on the IRA path for stack slot sharing
as
--- Comment #1 from burnus at gcc dot gnu dot org 2008-09-12 19:59 ---
This makes running 4.3 programs with the 4.4 libraries impossible,
as the library will receive garbage on its eigth argument.
Why? The first argument should tell how many arguments exists.
set_options has:
if
Given the following code:
volatile struct {
unsigned char a: 1;
} bits;
unsigned char
getfoo(void)
{
while (bits.a 3)
/* wait */;
return 42;
}
GCC does not emit a warning with -Wall -Wextra yet happily generates an
infinite loop since the while condition
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-09-12 20:02 ---
Ops, you're right.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
While trying to compile PPL using a gcc that targets Win64, an autoconf test
for a remainder bug fails. The test basically tries to compute INT_MIN % -1.
The program compiles cleanly, but execution results in a crash with exit code
149. The compile line is without any -O optimization, and with
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-12 20:17 ---
INT_MIN % -1 is undefined as INT_MIN/-1 is undefined. The reason why
INT_MIN/-1 is undefined is because - INT_MIN overflows. So this is not a GCC
bug but a PPL bug. Report this to them.
--
pinskia at gcc
--- Comment #2 from nightstrike at gmail dot com 2008-09-12 20:32 ---
Re-opening, valid PR as per 30484. Will close as duplicate.
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #3 from nightstrike at gmail dot com 2008-09-12 20:32 ---
Marking as duplicate of 30484.
*** This bug has been marked as a duplicate of 30484 ***
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #7 from nightstrike at gmail dot com 2008-09-12 20:32 ---
*** Bug 37503 has been marked as a duplicate of this bug. ***
--
nightstrike at gmail dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-12 20:33 ---
(In reply to comment #1)
It is caused by revision 140285.
That does not mean there is a bug in IRA.
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from paul dot isaacson at earthlink dot net 2008-09-12
20:41 ---
Subject: RE: parallel/base.h log2 conflicts with math.h
Unfortunately I don't have a simple test case, but it's not too hard to
reproduce:
Download stxxl.1.2.1 and attempt to make it with pmode enabled.
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-09-12 20:41 ---
Note libgcc functions would only need to get it right for CPUs defining the
macro, if in other cases the source checks would be inserted anyway. Or the
macro could depend on the mode of the division/modulo operation.
--- Comment #6 from burnus at gcc dot gnu dot org 2008-09-12 20:42 ---
This is equivalent to the ever popular use of EQUIVALENCE to set a
real type to Inf or NaN via integers.
Actually, it is a bit different: Here, already the COMMON is invalid for
EQUIVALENCE only accessing the
--- Comment #8 from jsm28 at gcc dot gnu dot org 2008-09-12 20:39 ---
I suggest an option such as -fdivide-checks, off by default. -std=c99 and
other conformance options, for languages where INT_MIN % -1 is defined, would
enable this option unless -fno-divide-checks is specified by the
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-12 20:49 ---
The problem is this harmless looking variable in the program (from
-fdump-tree-original):
struct __st_parameter_dt dt_parm.2;
This struct matches st_parameter_dt in libgfortran/io/io.h. If one compares
--- Comment #7 from andreast at gcc dot gnu dot org 2008-09-12 21:07
---
Thanks!
First results here, but with disable-checking:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01060.html
Same version is now building w/o disable-checking.
--
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/73c7b88ffbe8e1d5
The following (see URL above) is valid but gfortran rejects it with:
Error: Pointer assignment target has PROTECTED attribute at (1)
C538:
A pointer object that has the PROTECTED attribute and is
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-12 21:17 ---
Created an attachment (id=16308)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16308action=view)
A testcase
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -S /tmp/x.ii
--- Comment #7 from kargl at gcc dot gnu dot org 2008-09-12 21:18 ---
(In reply to comment #6)
This is equivalent to the ever popular use of EQUIVALENCE to set a
real type to Inf or NaN via integers.
Actually, it is a bit different: Here, already the COMMON is invalid for
--- Comment #8 from dominiq at lps dot ens dot fr 2008-09-12 21:31 ---
If I recall correctly, the commons do not need to have the same size
5.7.2.5 Differences between named common and blank common (F2008, 5.5.2.4 for
f95)
...
Named common blocks of the same name shall be of the
--- Comment #14 from vmakarov at gcc dot gnu dot org 2008-09-12 22:56
---
Subject: Bug 37377
Author: vmakarov
Date: Fri Sep 12 22:55:23 2008
New Revision: 140325
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140325
Log:
2008-09-12 Vladimir Makarov [EMAIL PROTECTED]
--- Comment #2 from spop at gcc dot gnu dot org 2008-09-12 23:05 ---
Subject: Bug 37484
Author: spop
Date: Fri Sep 12 23:03:54 2008
New Revision: 140327
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140327
Log:
2008-09-12 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #3 from spop at gcc dot gnu dot org 2008-09-12 23:08 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #10 from brian at dessent dot net 2008-09-12 23:59 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
One thing I was unsure about is this method switches to the .bss section
without switching back to .text (or whatever)
--- Comment #3 from dominiq at lps dot ens dot fr 2008-09-13 00:09 ---
Subject: Re: FAIL: gcc.c-torture/compile/vector-4.c
Can you add ...
With /* { dg-do compile } */ the tests pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37495
--- Comment #9 from reichelt at gcc dot gnu dot org 2008-09-13 01:12
---
This has been fixed on mainline between 2008-06-26 and 2008-07-05.
I think this was 'fallout' from
2008-07-02 Jason Merrill [EMAIL PROTECTED]
* Make-lang.in (cp/typeck2.o): Add $(REAL_H) dependency.
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-09-13 01:23
---
The bug reappeared on the 4.3 branch.
It remains fixed on mainline, though.
So no status change since it's not a regression.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-13 01:53 ---
g++.dg/cpp0x/variadic-tuple.C fails for me with an ICE during GC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37500
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-13 03:52 ---
Here is a reduced testcase for the variadic-tuple.C failure.
Compile with --param ggc-min-expand=0 --param ggc-min-heapsize=0 -w:
namespace std __attribute__ ((__visibility__ (default))) {
templatetypename _CharT
1 - 100 of 103 matches
Mail list logo
