--- Comment #1 from burnus at gcc dot gnu dot org 2008-08-24 06:36 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-08/msg00190.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-24 08:39 ---
Well, it seems that revision included enabling ipa-cp by default at -O2 ;)
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139525
Log:
* ipa-cp.c (constant_val_insert): Remove.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37218
--- Comment #2 from bonzini at gnu dot org 2008-08-24 08:53 ---
yes, definitely a regression. it would be good to test on a few architectures
though (ppc, spu, x86?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
--- Comment #3 from etienne_lorrain at yahoo dot fr 2008-08-24 09:13
---
Moreover, if in the first test.c program, you declare variable conf
volatile,
the assembly generated contains 8 writes to conf, and that memory location
is *read* 7 times. If conf does not point to memory but to
--- Comment #2 from dominiq at lps dot ens dot fr 2008-08-24 09:17 ---
Well, it seems that revision included enabling ipa-cp by default at -O2 ;)
May this explain the following failures (i686-apple-darwin9):
[ibook-dhum] f90/bug% gfc -O2
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-24 10:02 ---
As PR 37201 shows, testing result = funct() is not enough, one should also
test otherfunc(func()) and print *, func(). (Though the problems will
probably be solved by the fix for PR 37201.)
--
--- Comment #4 from burnus at gcc dot gnu dot org 2008-08-24 10:38 ---
One could work around the bug: As such conversions are not valid, one just
needs to reject them with -pedantic (cf. PR 37173) ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
--- Comment #1 from ubizjak at gmail dot com 2008-08-24 11:26 ---
Please look at the asm dump (add -S to compile flags) for following lines:
.globl iint
.bss
.align 4
.type iint, @object
.size iint, 4
iint:
.zero 4
.comm
--- Comment #2 from simon dot sasburg at gmail dot com 2008-08-24 11:35
---
with -S added:
.globl _iint
.bss
.align 4
_iint:
.space 4
.comm _iarr, 256 # 256
.section .rdata,dr
.align 16
with -S -fno-common added:
.globl _iint
--- Comment #3 from jh at suse dot cz 2008-08-24 11:37 ---
Subject: Re: [4.4 Regression] Revision 139525 caused many SLP regressions
or should I open another PR?
I've reverted the accidental commit as well as fixed this problem, so I
hope it is all OK.
Honza
--
--- Comment #3 from brian at dessent dot net 2008-08-24 11:48 ---
Subject: Re: [cygwin] Invalid alignment for SSE store to .comm
data generated with -O3
The the 3 argument version of .comm is only supported by the ELF
assembler so it would be rejected by the PE assembler if gcc were
--- Comment #3 from razya at il dot ibm dot com 2008-08-24 12:28 ---
(In reply to comment #2)
*** Bug 37165 has been marked as a duplicate of this bug. ***
Submitted:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01789.html
I now see no failures in matrix reorg suite.
--
--- Comment #4 from brian at dessent dot net 2008-08-24 12:47 ---
Subject: Re: [cygwin] Invalid alignment for SSE store to .comm
data generated with -O3
Also, this is not Cygwin-specific as far as I can tell, more like
PE-specific since it affects MinGW as well.
--
Hi,
during cross compilation on amd64 host to arm target I get the followng ICE:
arm-v4t-linux-gnueabi-gcc -c -D_GNU_SOURCE -I proc -isystem
/home/mkl/pengutronix/phytec/OSELAS.BSP-phyCORE-trunk/platform-phyCORE-i.MX27-glibc-2.8/sysroot-target/include
-isystem
--- Comment #1 from mkl at pengutronix dot de 2008-08-24 12:49 ---
Created an attachment (id=16136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16136action=view)
minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
I have the following testcase:
#include math.h
#define N 256
#define M 256
double mat1[N][3];
int mat2[M][4];
double point = 0;
int tmp;
double
foo ()
{
int i, j, k, l, ntimes;
int arr[4];
for (ntimes = 0; ntimes 5000; ntimes++)
{
for (i = 0; i M; i++)
{
--- Comment #7 from rda at lemma-one dot com 2008-08-24 14:02 ---
The gcc 4.4 semantics as described by Manuel do not conform to the standard in
either case. B2 is the integer -1 which is less than 0, so B2 0 should be 1
not 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-24 14:13 ---
After applying the patch in comment #3, the ICE disappeared. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37185
--- Comment #33 from dominiq at lps dot ens dot fr 2008-08-24 16:46 ---
All the results for 32-bit mode only, but I am pretty confident that they will
hold with -m64.
This is wrong: the tests pass in 32-bit mode, but fail with -m64.
--
--- Comment #34 from dominiq at lps dot ens dot fr 2008-08-24 16:50 ---
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c
[ibook-dhum] f90/bug% grep ffoo1a weak-2.s
movq[EMAIL PROTECTED](%rip), %rax
--
In 4.5.6.2 of the draft F2003 standard (Type-bound procedure overriding) a
list of conditions is given that an overriding type-bound procedure must
satisfy; the checks that function result characteristics and characteristics of
corresponding dummy arguments are the same are incomplete in the
--- Comment #5 from burnus at gcc dot gnu dot org 2008-08-24 17:18 ---
Subject: Bug 37201
Author: burnus
Date: Sun Aug 24 17:16:46 2008
New Revision: 139537
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139537
Log:
2008-08-24 Tobias Burnus [EMAIL PROTECTED]
PR
This nights trunk fails (gcc of Aug 19th was still fine) with:
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree-form -D__GFORTRAN -D__FFTSG -g -v pw_spline_utils.F
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-24 18:05 ---
Created an attachment (id=16137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137action=view)
testcase
untar and compile with
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
--- Comment #3 from eric dot weddington at atmel dot com 2008-08-24 18:21
---
Patch in bug #37185, comment #3, does not fix this bug. Bug #37185 has to do
with transpose-3.c and is an ICE. This bug has to with a failure of matrix-1.c
and is not an ICE.
--
eric dot weddington at
--- Comment #4 from eric dot weddington at atmel dot com 2008-08-24 18:31
---
(In reply to comment #3)
Patch in bug #37185, comment #3, does not fix this bug.
Meh. Bad patching job by me. Retesting patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37165
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:34 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:42 ---
(In reply to comment #1)
Created an attachment (id=16137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137action=view) [edit]
testcase
untar and compile with
gfortran -c -O3 -ffast-math
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-08-24 18:46 ---
Works for 4.2; original test case:
$ gfortran xpar.f90
$ ./a.out
FFFTTTFTFFTFFTF
FFF
$ gfortran-4.2 xpar.f90
$ ./a.out
Intel Fortran has a notation to specify C string literals by appending the
letter C at the end of the string. See here for an example:
http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/lref_for/source_files/pgcchcs.htm
It would be nice to have this, or something
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-24 19:13 ---
(In reply to comment #2)
(In reply to comment #1)
Created an attachment (id=16137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137action=view) [edit]
testcase
untar and compile with
gfortran -c
--- Comment #5 from razya at gcc dot gnu dot org 2008-08-24 19:40 ---
Subject: Bug 37185
Author: razya
Date: Sun Aug 24 19:39:04 2008
New Revision: 139539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139539
Log:
2008-08-24 Razya Ladelsky [EMAIL PROTECTED]
PR
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-08-24 19:45
---
gfortran does have -fbackslash that enables c-style interpretation of backslash
characters in strings.
With the Intel approach, the code will not compile without error by a standard
conforming compiler. I would
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-24 20:00 ---
Created an attachment (id=16138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16138action=view)
Fortran only testcase
compile as:
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
--- Comment #5 from ubizjak at gmail dot com 2008-08-24 20:12 ---
Confirmed and added maintainer CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-08-24 20:26 ---
FYI: I also suggested that they look into gfortran's work on implementing new
character kinds such as UTF-8.
That part is defined in the Fortran 2003 standard (optional) and the
almost-ISO-approved Fortran 2008
--- Comment #6 from burnus at gcc dot gnu dot org 2008-08-24 20:31 ---
FIXED on the trunk (4.4).
Thanks for reporting the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-24 20:32 ---
Subject: Bug 37201
Author: burnus
Date: Sun Aug 24 20:31:09 2008
New Revision: 139545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139545
Log:
2008-08-24 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-08-24 20:34 ---
I think this was fixed by reverting the patch which turned on IPA-CP by
default. Also I think this was really fixed by
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01104.html.
--
--- Comment #6 from brian at dessent dot net 2008-08-24 20:59 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
It seems to me the issue is that prior to 2007-11-05[1], the PE
assembler could not set section alignment flags correctly so .bss
--- Comment #7 from brian at dessent dot net 2008-08-24 21:15 ---
Subject: Re: [cygming] Invalid alignment for SSE store to
.comm data generated with -O3
Another route would be to set the .bss minimum back to 2**4 again.
Actually that's not really great either because it doesn't
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 21:29 ---
Well it is not prohibited, it is supported to do the build in the src
directory, just not recommended as it is not tested really and can (I think
4.3.x has a bug dealing with fixed includes) be broken even for
--- Comment #10 from manu at gcc dot gnu dot org 2008-08-24 21:31 ---
I think we should mark as SUSPENDED those enhancement requests where there is
no consensus that we actually want the feature, even if a patch were available.
It would be a waste of time to implement this just to have
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:04 ---
There are a couple of issues here I think. The first being that the loop:
for (j = 0; j 4; j++)
arr[j] = mat2[i][j];
is not being unrolled.
If I specify -fpeel-loops, it is unrolled but
--- Comment #2 from tom dot browder at gmail dot com 2008-08-24 22:07
---
Andrew, you're right--it's not prohibited, but my argument is that it should be
prohibited as the default build (but have a specific configure variable to
allow it), at least until it is tested. Over the years
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:12 ---
Confirmed, I don't know if this is a regression or not.
Program received signal SIGSEGV, Segmentation fault.
0x1006f204 in preprocess_file (pfile=0x10a03728) at
/home/apinski/src/local/gcc/gcc/c-ppoutput.c:88
88
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-24 22:20 ---
Reducing, -Wconversion causes the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-24 22:27 ---
Confirmed, reduced testcase:
int __convert_from_v( ) {
char* __old;
if (__builtin_strcmp(__old, C)) {}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:28 ---
I think GCC is correct here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:40 ---
Confirmed. One issue is that VRP does not look again at some % statements when
it knows it can be a constant so we produce:
D.1962_10 = 0;
D.1963_11 = (int) D.1962_10;
Here is a more reduced testcase:
func_18
--- Comment #2 from akyrtzi at gmail dot com 2008-08-24 22:42 ---
I forgot to mention that both MSVC and Comeau compilers interpret
FuncType(a)(x,y)-z = 0;
as expression and compile the test program without errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37213
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-24 22:46 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37153
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Summary|vectorizer issue
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37157
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-24 22:53 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37189
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 22:55 ---
Confirmed also on PowerPC 64 GNU/Linux.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE when gcc 4.4.0-20080730 |[4.4 Regression] ICE when
|compile lapack
--- Comment #12 from gnu_andrew at member dot fsf dot org 2008-08-24 23:28
---
Futureproofing:
CVSROOT:/sources/classpath
Module name:classpath
Changes by: Andrew John Hughes gnu_andrew 08/08/21 20:46:20
Modified files:
. : ChangeLog
m4
The program snippet below shows that GCC/g++ uses an incorrect
instantiation context leading to program miscompilation.
In particular, there is only one instantiation context for g(),
and in that instantiation context, the second f() is inexistant
therefore should not be considered.
#include
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-24 23:32 ---
I think this is a dup of bug 16635.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from eric dot weddington at atmel dot com 2008-08-25 00:09
---
(In reply to comment #4)
(In reply to comment #3)
Patch in bug #37185, comment #3, does not fix this bug.
Meh. Bad patching job by me. Retesting patch...
Confirmed: patch in bug #37185 does not fix
Test regressions on AVR target, known for trunk revision 139546:
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp versioned function 2
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp replacing param with const 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times cp versioned function 2
FAIL:
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37226
--- Comment #35 from hp at gcc dot gnu dot org 2008-08-25 01:26 ---
Created an attachment (id=16139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16139action=view)
Testcase exposing the (on darwin) breaking aspect of prims.ii
See comments in the test-case. The test-case breaks
On Linux/ia32, Revision 139545 gave
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp versioned function 2
FAIL: gcc.dg/ipa/ipa-1.c scan-ipa-dump-times cp replacing param with const 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times cp versioned function 2
FAIL: gcc.dg/ipa/ipa-2.c scan-ipa-dump-times
--- Comment #36 from hp at gcc dot gnu dot org 2008-08-25 01:48 ---
Created an attachment (id=16140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16140action=view)
Weak testing weak: testing weak stronger.
I was missing tests that referenced a weak address, but offset, and the
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-25 02:03 ---
Reduced testcase:
struct optional_base {
optional_base() {}
optional_base ( optional_base const rhs ) {}
};
struct Point_container { optional_base m_b ; };
int create_internal_node(Point_container c)
{
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-25 02:05 ---
We are gimplifying the copy constructor while gimplifying something else ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37189
--- Comment #37 from hp at gcc dot gnu dot org 2008-08-25 02:09 ---
Created an attachment (id=16141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141action=view)
Patch, take 4.
Fourth time's a charm.
The difference is just strengthening the early-return in assemble_external so
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-25 03:47 ---
*** Bug 37226 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-25 03:47 ---
*** This bug has been marked as a duplicate of 37227 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-25 04:32 ---
I have it tested on i386-darwin, spu-elf both without any regressions. The
PowerPC64-linux-gnu run is still working on so far no regressions. I will
submit this tomorrow.
--
--- Comment #3 from eric dot weddington at atmel dot com 2008-08-25 05:22
---
These tests have also failed on AVR recently. Known fail on revision 139139.
And no, this is not a duplicate of 37170, as the patch for that bug fixes those
test cases, but does not fix these.
--
eric
76 matches
Mail list logo
