--- Comment #6 from janus at gcc dot gnu dot org 2009-02-27 09:01 ---
On x86_64-unknown-linux-gnu I *do* get the ICE when I compile with -ffast-math
-mfpmath=387. Cf. http://gcc.gnu.org/ml/fortran/2008-11/msg00250.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314
--- Comment #7 from janus at gcc dot gnu dot org 2009-02-27 09:13 ---
Note that the problem also appears for log, while it does not for acosh and
atanh:
real :: x = -5.0
! FPE is not thrown
print *, log(x)
print *, log10(x)
print *, acos(x)
print *, asin(x)
! FPE is thrown
!print *,
--- Comment #2 from oliver dot kellogg at eads dot com 2009-02-27 09:28
---
FWIW, pressing Ctrl-C in gdb when the program blocks shows following trace:
Program received signal SIGINT, Interrupt.
0x0805bbd1 in system.soft_links.task_lock_nt () at s-soflin.adb:295
295procedure
--- Comment #10 from schwab at suse dot de 2009-02-27 09:57 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #21 from pluto at agmk dot net 2009-02-27 10:29 ---
(In reply to comment #20)
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
waht about this testcase?
the bug is marked as fixed but
--- Comment #22 from rguenther at suse dot de 2009-02-27 10:33 ---
Subject: Re: [4.4 regression] warnings from -isystem
headers strikes back.
On Fri, 27 Feb 2009, pluto at agmk dot net wrote:
--- Comment #21 from pluto at agmk dot net 2009-02-27 10:29 ---
(In reply to
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-27 10:47 ---
FIXED on the trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from burnus at gcc dot gnu dot org 2009-02-27 10:49 ---
Note that the problem also appears for log, while it does not for acosh and
atanh:
If it works with some but not all libm routines, it sounds more like a GLIBC
than like a GCC problem.
--
--- Comment #23 from pluto at agmk dot net 2009-02-27 11:04 ---
(In reply to comment #22)
The original reported problem is gone. The testcase below is unfixable.
so what users can do now?
the -isystem feature doesn't work as expected with this unfixable diagnostics.
--
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-02-27 11:07
---
The user can use -Wno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
--- Comment #25 from pluto at agmk dot net 2009-02-27 11:22 ---
(In reply to comment #24)
The user can use -Wno-strict-aliasing.
naturally, but -O2 turns on -fstrict-aliasing, so using strict-aliasing
without warnings about aliasing violations is a bit horrible :)
--
--- Comment #26 from rguenther at suse dot de 2009-02-27 12:04 ---
Subject: Re: [4.4 regression] warnings from -isystem
headers strikes back.
On Fri, 27 Feb 2009, pluto at agmk dot net wrote:
--- Comment #25 from pluto at agmk dot net 2009-02-27 11:22 ---
(In reply to
--- Comment #9 from janus at gcc dot gnu dot org 2009-02-27 13:15 ---
(In reply to comment #8)
If it works with some but not all libm routines, it sounds more like a GLIBC
than like a GCC problem.
Can someone reproduce this with C code?
--
--- Comment #11 from joel at gcc dot gnu dot org 2009-02-27 16:24 ---
Laurent.. what Makefile magic is needed to select this file on sh Ada targets
and not on others?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
--- Comment #12 from aesok at gcc dot gnu dot org 2009-02-27 16:25 ---
2007-04-05 Anatoly Sokolov ae...@post.ru
PR target/25448
* config/avr/avr.c (avr_handle_fndecl_attribute): Use the
DECL_ASSEMBLER_NAME, not the DECL_NAME.
--
--- Comment #2 from joel at gcc dot gnu dot org 2009-02-27 16:26 ---
Ping.. still broken
gcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
--- Comment #3 from joel at gcc dot gnu dot org 2009-02-27 16:28 ---
Laurent.. would it make sense to have a low memory alternate version of the
file in question and swap it in on some targets like the sh2e issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
--- Comment #14 from spop at gcc dot gnu dot org 2009-02-27 16:42 ---
Subject: Bug 39308
Author: spop
Date: Fri Feb 27 16:42:38 2009
New Revision: 144470
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144470
Log:
2009-02-27 Sebastian Pop sebastian@amd.com
PR
--- Comment #15 from spop at gcc dot gnu dot org 2009-02-27 16:43 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from laurent at guerby dot net 2009-02-27 17:42 ---
First you need to find out which stack_size works on your target.
An obvious patch would be something like that:
Default_Env_Stack_Size : constant Size_Type := Size_Type'Min (8_192_000,
Size_Type'Last / 1024 );
--- Comment #12 from laurent at guerby dot net 2009-02-27 17:50 ---
There is no need for Makefile magic here, this is a bug in s-scaval.adb logic.
As I said this file is used for only one ACATS test and one specific and not
widely used feature, so for the purpose of testing RTEMS you
The attached code produce an ICE (below) with cuurent trunk when the compiler
option includes all of '-fno-second-underscore -fexceptions -O3'. The code
compiles fine with gfortran-4.3.2.
..
[d...@logos gemclim33]$ gfc -c -m64 -fPIC -fcray-pointer -fconvert=big-endian
-fopenmp
--- Comment #1 from deji_aking at yahoo dot ca 2009-02-27 18:03 ---
Created an attachment (id=17371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17371action=view)
Fortran file that produce the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
--- Comment #2 from dominiq at lps dot ens dot fr 2009-02-27 18:24 ---
Confirmed oni686-apple-darwin9 with
gfc -c -fcray-pointer -fexceptions -O2 -ftree-vectorize adw_trajsp.f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
The sample program fails to run on Linux x86_64.
I'm using ...
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
... and compiling with command line ...
g++ -Os catch.cpp -o catch.exe
=== Program Output ===
./catch.exe
file = catch.cpp
Segmentation fault
=== SAMPLE Program ===
#include stdexcept
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 18:31 ---
3.4.6 is old and 3.4.x to 4.1.x are no longer maintained.This is most
likely a duplicate of bug 26530.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39319
--- Comment #3 from oliver dot kellogg at eads dot com 2009-02-27 18:42
---
Expanding on comment #2, there seems to be an endless loop around
s-fileio.adb:377ff.
376 Fptr1 := Open_Files;
377 while Fptr1 /= null loop
378 Fptr2 := Fptr1.Next;
379 Close
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-27 19:03 ---
Forgot to say that it is a [4.4 Regression].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
This occurred during the build. I would expect it to happen on m32c-elf also.
$ /home/joel/test-gcc/b-gcc1-m32c/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-m32c/./gcc/ --version
xgcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455]
/home/joel/test-gcc/install/m32c-rtems4.10/include
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-02-27 19:49 ---
Subject: Bug 39267
Author: hubicka
Date: Fri Feb 27 19:49:42 2009
New Revision: 144474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144474
Log:
PR debug/39267
* tree.h (TREE_PROTECTED): Fix
--- Comment #4 from dominiq at lps dot ens dot fr 2009-02-27 19:59 ---
Reduced test:
subroutine adw_trajsp ( F_lon, F_lat, F_x, F_y, F_z,
%F_u, F_v, F_dt,i0,in,j0,jn)
implicit none
real
The following program should compile, but current g++ from trunk compiles it.
Please read the comments in the code:
~=~
templatetypename T
struct do_typedef
{
typedef T type;
};
templatetypename T struct is_function;
// Let's name this template partial specialization #1
templatetypename T
--- Comment #1 from dodji at gcc dot gnu dot org 2009-02-27 20:06 ---
Created an attachment (id=17372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17372action=view)
Don't remove cv quals from typedefs during type substitution
--
--- Comment #2 from dodji at gcc dot gnu dot org 2009-02-27 20:08 ---
I have filed bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321 that
describes the gcc bug. It also has a patch that should fix it.
--
dodji at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from lanurmi at iki dot fi 2009-02-27 20:15 ---
Well yes, the meaning of basic block is not self-explanatory either. But at
least it is a much better search term than just 'BB'. And if someone comes up
with something even better, I'm certainly not against it.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 20:25 ---
*** This bug has been marked as a duplicate of 39182 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-27 20:25 ---
*** Bug 39320 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
--- Comment #3 from vegard dot nossum at gmail dot com 2009-02-27 20:27
---
I'm hitting this as well :-(
[veg...@damson ~/programming 0]
$ cat flexible-array-empty-struct.c
struct x {
union {
int x;
};
int array[];
};
[veg...@damson
--- Comment #4 from vegard dot nossum at gmail dot com 2009-02-27 20:32
---
Workaround:
Install an empty dummy member between the union and the array, like this:
struct x {
union {
int x;
};
int _dummy[0]; // workaround
int array[];
--- Comment #5 from joseph at codesourcery dot com 2009-02-27 20:58 ---
Subject: Re: struct with only anonymous unions plus flexible
array member
Anonymous unions are outside the scope of C99, so this issue is purely
about what is most useful for GNU C right now.
However, there
A IMHO the trunk issues a bogus warning for the following code snippet
when compiling it with -O2 -Wall using the C++ frontend:
==
int foo()
{
char a[10];
int i = *(int*)a[4];
int j = *(int*)(a+4);
return i+j;
}
==
bug.cc: In
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39322
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 22:23 ---
Actually this is not a bogus aliasing warning at all. You are accessing a
character type as an int which is an aliasing violation.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
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=39322
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-27 22:25 ---
We should give a warning on both lines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39322
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-27 22:37 ---
The FE warning code doesn't warn for *((int *) a + 4) because it doesn't
recognize the form. This is what we get in both cases from the C frontend
and in the second case from the C++ frontend.
The PTA warning code
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-27 22:52 ---
Related a little bit to bug 39117 or at least for the PTA side of things.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39322
struct tree_decl_common has
unsigned int align : 24;
And the maximum alignment we support is 1 23 bits (1 20 bytes). However,
config/elfos.h has
/* The biggest alignment supported by ELF in bits. 32-bit ELF
supports section alignment up to (0x8000 * 8), while
64-bit ELF supports
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-27 23:40 ---
If this is still a problem, please try the patch at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html
I'd rather not make changes like that so late in the release cycle but I'll do
it if it's needed and not
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39323
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-28 00:03 ---
Created an attachment (id=17373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17373action=view)
A new patch
This patch may work better.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-28 00:12 ---
Shouldn't handle_aligned_attribute check alignment overflow?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-28 00:25 ---
The GCC testsuite supports effective-target keywords which can be used anywhere
that target lists are used; see the internals manual about Test Directives.
Define an effective-target keyword xxx via
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-02-28 00:30
---
I have just posted a patch to fix this issue on the 4.3 branch to the
mailing list:
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01245.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
--- Comment #16 from skunk at iskunk dot org 2009-02-28 00:41 ---
Building 4.3.3 fails with
/usr/home/cport/tmp/bash ./libtool --tag=CXX --mode=compile
/usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc
-B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-02-28
01:01 ---
Created an attachment (id=17374)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17374action=view)
This patch fixes -save-temps so that it puts the temp file in the output
directory rather than the
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-28 02:03 ---
Created an attachment (id=17375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17375action=view)
An updated patch
When align == 0, we should align variable to STACK_BOUNDARY.
--
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-28
02:38 ---
Created an attachment (id=17376)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17376action=view)
testcase executable built on mingw32
testcase executable built on mingw32 attached
--
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-28
03:12 ---
Subject: Re: WARNING: Could not compile gcc.dg/compat/struct-layout-1
generator
If this is still a problem, please try the patch at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01496.html
Yes, this
--- Comment #5 from rob1weld at aol dot com 2009-02-28 03:53 ---
(In reply to comment #4)
In addition to the lack of -L... this is also a 'spec' issue :
...
The issue with the spec file is caused by this in the Makefile.in:
# Dump a specs file to make -B./ read these specs over
60 matches
Mail list logo
