On Mon, 2007-05-28 at 15:29 -0700, Mark Mitchell wrote:
Andrew --
I'm trying to firm up GCC 4.3 planning a bit. One of the things I'm
considering is whether or not the POINTER_PLUS branch should be merged
as part of 4.3. My understanding from looking at your emails is that
the branch is
Rask Ingemann Lambertsen wrote:
On Mon, May 28, 2007 at 05:14:51PM +, R. D. Flowers, Chattanooga TN USA
wrote:
I think we should use parentheses to enforce the order.
I could be missing something here, and it is almost separate statements,
and might be ugly, but -- comma clauses?
Lu
On Tue, May 29, 2007 at 03:10:57AM +, R. D. Flowers, Chattanooga TN USA
wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 28, 2007 at 05:14:51PM +, R. D. Flowers, Chattanooga TN
USA wrote:
foo=term1,foo+=term2,foo+=term3 ... ;
URL:http://gcc.gnu.org/bugs.html#nonbugs_c
Am I
Hi,
I'm working on a new target port in which there are different base
registers
allowed depending on the offset:
r0-r7 are allowed as base register only when the offset is zero.
r6-r7 are allowed as base register for every offset.
I'm wondering if gcc is prepared for such scenario, examine the
On Tue, May 29, 2007 at 03:56:38PM +0300, Tal Agmon wrote:
Hi,
I'm working on a new target port in which there are different base
registers
allowed depending on the offset:
r0-r7 are allowed as base register only when the offset is zero.
r6-r7 are allowed as base register for every
Rohit Arul Raj [EMAIL PROTECTED] writes:
I have defined a target hook TARGET_EXPAND_BUILTIN_SAVEREGS (GCC
4.1.1) as an alternative to TARGET_SETUP_INCOMING_VARARGS so as to
code ___builtin_saveregs as per my target. But this target hook is not
getting recognized.
Is there anything else
Andrew Pinski wrote:
I cleaned up the code today so it basically ready to be merged, some
(most?) of the target headers still need to be fixed for the change.
The list of targets which need to be changed is:
alpha ia64 mips pa
s390sparcstormy16xtensa
I don't have
Yaakov Yaari [EMAIL PROTECTED] writes:
LSDA (Language Specific Data Area) is used to store exception handling
information at the exception catch site, see
http://www.codesourcery.com/cxx-abi/exceptions.pdf.
For various kinds of binary analyzers (translators, optimizers) it is
useful to be
On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote:
On 5/28/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0
introduces a custom fields
Mark Mitchell wrote:
Chao-Ying, I'm also interested in whether or not these changes have any
impact on C++. With your changes, does GNU C++ now accept any
fixed-point constructs?
Chao-ying's on vacation this week. AFAIK Chao-ying's code does nothing explicit
to support, or not support,
If we segfault for printf(%d\n, 2+2), the bug would not be in this
category. If we printed 5, it would be.
So what if the printf statement is executed only once every leap year?
What if it segfaults only if you have one out of several thousand
address space randomization patterns?
Your
...as of rev 125166.
No surprises.
Aldy
Hello,
I read that the eh_frame is for exceptions support,
for languages like C++ for instance.
I wonder why when I compile standard C programs using gcc -v simple.c
I can see that the linker adds the --eh-frame-hdr parameter ?
After all there is no use for the eh section when we don't support
Daniel Berlin wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be
sfora dim [EMAIL PROTECTED] writes:
I read that the eh_frame is for exceptions support,
for languages like C++ for instance.
Yes.
I wonder why when I compile standard C programs using gcc -v simple.c
I can see that the linker adds the --eh-frame-hdr parameter ?
That option is always used
On 5/29/07, Jeffrey Law [EMAIL PROTECTED] wrote:
I haven't followed PTR_PLUS development at all -- what specifically
spurred you to hack on this Andrew?
For spu-elf, good alignment information is needed for each load/store
as each load/store is only done on 128bit alignment. Since we lose a
On May 25, 2007, at 12:26 PM, Thomas Neumann wrote:
Unfortunately reviewing as been, ahem, a bit slow.
:-( I'd ask if the SC has had any luck finding suitable reviewers
yet... I do think Fortran has about the right number judging from the
latency on patch review. They have about 1
On 5/29/07, Joe Buck [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote:
On 5/28/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
.
You can customize what fields are shown on the
Can anyone explain exactly how and when the file...
gcc/fixincludes/tests/base/architecture/ppc/math.h
is used when building gcc on Darwin PPC? I ask because I
just noticed that it contains the remapping of the long
double math calls to use the appended $LDBL128 suffix.
I am wondering if it
I am pleased to announce that the GCC Steering Committee has
appointed Dorit Nuzman, Richard Guenther, and Zdenek Dvorak as
Auto-Vectorizer maintainers.
Please join me in congratulating Dorit, Richard, and Zdenek on their
new role. Please update your listings in the MAINTAINERS
On 29 May 2007 15:27:43 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
I wonder why when I compile standard C programs using gcc -v simple.c
I can see that the linker adds the --eh-frame-hdr parameter ?
That option is always used if the linker supports it.
After all there is no use for
x.f90: In function 'MAIN__':
x.f90:2: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:3693
for:
real(kind(0d0)), parameter :: r(1) =
transfer(transfer(sqrt(2d0), (/ .true. /) ), (/ 0d0 /), 1)
print *,r
end
--
Summary: ICE with transfer in
--- Comment #5 from patchapp at dberlin dot org 2007-05-29 06:45 ---
Subject: Bug number PR31610
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-05/msg01953.html
--
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 06:51 ---
Hmm, rebuild and works for me.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
From the gfortran testsuite log:
Executing on host:
/Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../gfortran
-B/Users/brooks/gcc-trunk/build3/gcc/testsuite/gfortran/../../
/Users/brooks/gcc-trunk/svn-source/gcc/testsuite/gfortran.dg/func_result_3.f90
-O -pedantic-errors -S -o
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-29 07:27 ---
I should have noted: I think this showed up within the last week, but I can
confirm that it's not in my saved testsuite results from 2007-05-07.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32137
--- Comment #8 from kloedej at knmi dot nl 2007-05-29 07:29 ---
(In reply to comment #7)
Hi,
this is just to report that my code works again as expected.
Thanks a lot for the fast fix of this bug!
Jos de Kloe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32083
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-29 07:35 ---
Update: This isn't a regression; the testcase is new.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
Using
gfortran --version
GNU Fortran 95 (GCC) 4.3.0 20070131 (experimental)
uname -a
Linux loanamd25 2.6.12-rc1-mm-smp #13 SMP Fri Jun 3 17:14:40 BST 2005 x86_64
x86_64 x86_64 GNU/Linux
and compiling the file
begin gf_test.f90
WRITE(*,*) 'A continued comment
!'
END
end gf_test.f90
as
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-29 07:51 ---
Test case came from PR32088.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mathewc at nag dot co dot uk 2007-05-29 08:02 ---
I suppose that the code example could be made clearer if it were
begin gf_test.f90
WRITE(*,*) 'A continued string
!'
END
end gf_test.f90
for which the output is the same.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 08:05 ---
You might want to update your compiler: 4.3.0 20070131 is almost 5 months out
of date (in this case this is getting old because you are using a prerelease
after all).
This is a dup of bug 31495 which was fixed a
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-29 08:05 ---
*** Bug 32138 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dannysmith at gcc dot gnu dot org 2007-05-29 08:09
---
Subject: Bug 29498
Author: dannysmith
Date: Tue May 29 08:09:16 2007
New Revision: 125160
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125160
Log:
libgcc
PR target/29498
* config.host
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 08:16 ---
The error is in gfc_trans_dummy_array_bias, where the assert fails:
gcc_assert (GFC_ARRAY_TYPE_P (type));
The question is: Why does it fail on powerpc-apple but not on
x86_64-unknown-linux-gnu?
--
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-05-29
08:16 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #6 from pluto at agmk dot net 2007-05-29 08:50 ---
(In reply to comment #5)
Which shows for sure r may be used unitialized.
yes, but even if i catch possible i/o failure, gcc still produces warning.
--- auHexCastTest.ii.orig
+++ auHexCastTest.ii
@@ -18958,7 +18958,12
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-29 09:21 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pluto at agmk dot net 2007-05-29 10:17 ---
(In reply to comment #6)
+ str.exceptions ( stlp_std::istringstream::eofbit ||
stlp_std::istringstream::badbit || stlp_std::istringstream::failbit );
of course it should be '|' instead of '||' (shame on me)
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-29 10:39 ---
The patch below works and regtests OK. I am trying to devise a safe method of
gettting rid of the redundant symbols if none of the equivalence members is
USEd. If I cannot see something by tonight, I will submit
--- Comment #4 from jakub at gcc dot gnu dot org 2007-05-29 10:40 ---
When using gcc-3.2.3 as bootstrap compiler, i386.c is miscompiled
with -O0 -fkeep-inline-functions (the latter option is what is new
in gcc 4.2 and why 4.1.x bootstrap didn't suffer from this, see
2006-07-04 Eric
--- Comment #2 from dragzhb at yahoo dot com dot cn 2007-05-29 10:46
---
Sorry, I copy error.
it should be $GCC_SRC_ROOT\libstdc++-v3\include\ext\pb_ds\detail
I build it in another directory.
steps :
mkdir mingw_build
cd mingw_build
../gcc-4.2.0/configure --with-gcc --with-gnu-ld
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-29 10:47
---
Now, gcc-3_2-branch is long time closed, so IMNSHO gcc-4.2+ should work around
this bug.
Agreed, we can simply say that GCC 3.2.x is not is a GCC version that supports
it. Would you mind writing the patch? I
--- Comment #4 from andrew dot stubbs at st dot com 2007-05-29 10:57
---
Well, obviously I'll let people who really understand the details of this
decide whether it can be solved.
However, on the principle that warnings which one can safely ignore, but cannot
silence, are at best
--- Comment #5 from gdr at cs dot tamu dot edu 2007-05-29 11:11 ---
Subject: Re: warning: deleting void* is undefined sometimes bogus
andrew dot stubbs at st dot com [EMAIL PROTECTED] writes:
| Well, obviously I'll let people who really understand the details of this
| decide whether
--- Comment #6 from andrew dot stubbs at st dot com 2007-05-29 11:18
---
It's a cut down example to demonstrate the problem, not real world code.
I do ignore warnings in code that does exactly what I want it to do, provided
that I understand them.
--
--- Comment #29 from markus dot duft at salomon dot at 2007-05-29 11:37
---
Hi everybody!
gcc 4.2.0 works fine on interix 3.5 using the native binutils (at least as and
ld must be native...) with patch i will attach, and the following commands:
$ ../gcc-4.2.0/configure
--- Comment #30 from markus dot duft at salomon dot at 2007-05-29 11:40
---
Created an attachment (id=13625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13625action=view)
GCC 4.2.0 on interix 3.5
The patch includes the two previous diffs posted here.
--
--- Comment #6 from jakub at gcc dot gnu dot org 2007-05-29 11:42 ---
Seems there were 2 separate bugs that are causing this miscompilation.
1) common_type (in contemporary gcc's common_pointer_type) will for the type
of the whole conditional expression use pointer to attribute const
--- Comment #31 from markus dot duft at salomon dot at 2007-05-29 12:13
---
Created an attachment (id=13626)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13626action=view)
Fixed GCC 4.2.0 on interix 3.5
The patch includes the two previous diffs posted here.
This is a fixed
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-29 12:23 ---
Seems to be essentially back to the old speed. - Close
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from manu at gcc dot gnu dot org 2007-05-29 12:26 ---
(In reply to comment #6)
It's a cut down example to demonstrate the problem, not real world code.
Could you provide an example of real-world code where the warning is triggered?
We would prefer minimal but anything
--- Comment #8 from manu at gcc dot gnu dot org 2007-05-29 12:31 ---
(In reply to comment #6)
so, is it still an invalid testcase?
Does the warning show up with -O1 and -O2 ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pluto at agmk dot net 2007-05-29 12:35 ---
(In reply to comment #8)
(In reply to comment #6)
so, is it still an invalid testcase?
Does the warning show up with -O1 and -O2 ?
only with -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #10 from pluto at agmk dot net 2007-05-29 12:42 ---
Created an attachment (id=13627)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13627action=view)
update for the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32132
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-29 12:48 ---
2) is apparently PR11557, fixed in GCC 3.3.1+.
So, I'd say as workaround we should not use -fkeep-inline-functions for
GCC 3.3.1. Testing a patch for that.
--
jakub at gcc dot gnu dot org changed:
--- Comment #11 from manu at gcc dot gnu dot org 2007-05-29 12:57 ---
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #6)
so, is it still an invalid testcase?
Does the warning show up with -O1 and -O2 ?
only with -O3.
That is a bug by
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-29 13:17 ---
(In reply to comment #3)
Paul, I don't think that's solving the right problem. The code is legal; the
inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which
conforms with a CHARACTER scalar of
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-29 13:22
---
The __div0 function is called by the division routines when an attempt to
divide by zero is detected. On a linux system, it is expected that this will
cause SIGFPE to be raise(3)d, so the default implementation
int foo (void);
int bar (void) __attribute__((const));
int
test (int x)
{
int a = (x == 1 ? foo : bar) ();
int b = (x == 1 ? foo : bar) ();
return a + b;
}
ICEs in mark_operand_necessary.
3.4.x works and so does 4.2 and trunk.
Related to in PR29382 described common_pointer_type,
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-29 13:39 ---
(In reply to comment #4)
I misunderstood something slightly in that last comment; MERGE is elemental,
so
the conforming I mentioned doesn't matter. Also, my guess that fixing the
transfer(A, x, 20) problem would
--- Comment #2 from ian at airs dot com 2007-05-29 13:48 ---
I think that having -Wall clobber -Wstrict-overflow in this way is confusing.
This isn't reversing the setting of the option, it's changing its level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
--- Comment #8 from burnus at gcc dot gnu dot org 2007-05-29 14:05 ---
In reducing this, I discovered that gfortran currently hangs on the following
much simpler code. I suspect that if we fix this, it'll fix the original code
too.
write(*,*) transfer(A, x, 20)
NAG f95 and g95
--- Comment #9 from dominiq at lps dot ens dot fr 2007-05-29 14:25 ---
This gives still a warning with g95 and NAG f95;
NAG outputs Abb,
ifort/g95/sunf95 show .
Since a(:) is not initialized, the output can be anything.
with
a = .false.
a(1) = .true.
I
The following (reduced from CP2K, PR 29975) generates wrong code with gfortran
(gcc version 4.3.0 20070526)
MODULE TEST
CONTAINS
PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a)
CHARACTER(LEN=*), INTENT(IN) :: s1, s2, s3
CHARACTER(LEN=4), DIMENSION(3):: a
a(1)=s1; a(2)=s2;
--- Comment #104 from jv244 at cam dot ac dot uk 2007-05-29 15:07 ---
Even at optimisations levels lower than the one needed to generate the ICE of
PR 32096 (thanks tobias burnus), CP2K seems miscompiled. One possible testcase
has been added as PR 32140.
--
--- Comment #8 from sabre at nondot dot org 2007-05-29 15:14 ---
Right, you could do that, but it is a) not guaranteed to work going forward,
and b) expects properly structured (e.g. nested) control flow.
If I had b, I could just make a vla :)
-Chris
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-29 15:32 ---
Regression happens between 2007-05-25-r125057 and 2007-05-29-r125159.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-29 15:41 ---
I assume this is another incarnation of this bugs but leads to a segfault and a
slightly different valgrind output:
MODULE TEST
CONTAINS
PURE FUNCTION s2a_3(s1,s2,s3) RESULT(a)
CHARACTER(LEN=*), INTENT(IN)
A POD struct is not correctly initialized when default
initialization is requested in the initialization list of a
constructor, and it is a base class. Consider the following
program:
-
#include iostream
#include memory
#include stdlib.h
#include
When compiling the attached file, g++ crashes.
Trying to reduce the file size, random crashes occurred, ranging from endless
loops to glibc detecting memory corruption.
Removing the #line directives cures the crash.
Call:
g++ -O3 -fprofile-arcs pp.C
--
Summary: gcc crashes when
--- Comment #1 from dominik dot strasser at onespin-solutions dot com
2007-05-29 17:29 ---
Created an attachment (id=13628)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13628action=view)
bzip2ed preprocessor output for reproducing the crash.
--
--- Comment #5 from tkoenig at alice-dsl dot net 2007-05-29 17:47 ---
Subject: Re: knowing that stride==1 when using
allocated arrays and escaping allocatable arrays
On Tue, 2007-05-29 at 04:52 +, pinskia at gcc dot gnu dot org wrote:
we think we change a's stride
which
--- Comment #6 from jb at gcc dot gnu dot org 2007-05-29 17:51 ---
Reopening. This vectorizes only partly, with -ffast-math to boot. We should be
able to vectorize it without doing any unsafe math.
gfortran -O2 -ffast-math -march=native -mfpmath=sse -ftree-vectorize
Because of the patch for PR19238, make_decl_rtl is called before the visibility
of variables is determined.
You can see this when you compile g++.old-deja/g++.mike/ns12.c with -fpic.
default_binds_local_p_1 (decl, 1) does not return true for
(anonymous namespace)::i when its decl rtl is created,
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-29 18:09 ---
More regression hunting: FAILS with r125059, Works with r125057.
Conclusion: The patch causing or revealing this wrong-code error is:
r125058 | rguenth | 2007-05-25 11:07:29 +0200 (Fr, 25 Mai 2007) | 10 lines
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-29 18:13 ---
I am currently looking at the implementation of signal, so adding this may be
not too much effort. Some questions/remarks:
The third argument flag is an integer that plays the role of SIG_DFL
in the C library
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-29 18:15 ---
I assume this is another incarnation of this bugs but leads to a segfault and
a slightly different valgrind output
This test works for me with gfortran as of this morning and also with gfortran
r12505 (on
--- Comment #9 from rob1weld at aol dot com 2007-05-29 18:21 ---
Created an attachment (id=13629)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13629action=view)
Fix Cygwin __sgetc_r bug with GCC 4.3.0
The information above is for patching the _source_ tree.
If you obtained
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-29 18:26 ---
Plus forwprop only does:
D.1046_37 = (*__result.0_23)[0];
D.1048_41 = (char *) _s1_2(D);
D.1049_42 = D.1046_37 + D.1048_41;
Into:
D.1046_37 = (*__result.0_23)[0];
...
D.1048_41 = (char *) _s1_2(D);
--- Comment #5 from brooks at gcc dot gnu dot org 2007-05-29 18:45 ---
As of SVN 125160, this is working again. Weird, indeed.
I guess I'll close it as a chimera.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--- Comment #5 from jdgressett at amli-denton dot com 2007-05-29 18:59
---
(In reply to comment #4)
Now ACATS c380004 passes in gcc-4.3-20070518.
But it is still in the relesed 4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
Hello,
I get an ICE when compiling linux-2.6.20 with a host-gcc from today's
pointer_plus branch.
gcc -m32 -Wp,-MD,fs/hfs/.extent.o.d -nostdinc -isystem
/home/mstein/host-gcc/pointer_plus-2007-05-29/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-29 19:11
---
Created an attachment (id=13630)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13630action=view)
from linux-2.6.20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32144
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 19:15 ---
I have a fix, just reducing the testcase right now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
I get an ICE when compiling linux-2.6.20 with a host-gcc from today's
pointer_plus branch.
gcc -m32 -Wp,-MD,fs/xfs/.xfs_dir2.o.d -nostdinc -isystem
/home/mstein/host-gcc/pointer_plus-2007-05-29/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-05-29 19:37
---
Created an attachment (id=13631)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13631action=view)
from linux-2.6.20
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32145
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 19:37 ---
Reduced testcase:
typedef unsigned short __u16;
typedef unsigned int u32;
typedef __u16 __be16;
struct hfs_extent {
__be16 count;
};
int hfs_free_fork( int type)
{
u32 total_blocks, blocks, start;
struct
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-29 19:40 ---
The fix:
Index: ../../gcc/tree-chrec.c
===
--- ../../gcc/tree-chrec.c (revision 125151)
+++ ../../gcc/tree-chrec.c (working copy)
@@ -107,7
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 19:49 ---
I have a fix, just getting a reduced testcase (the ICE comes from VRP).
The fix is:
Index: ../../gcc/tree-vrp.c
===
--- ../../gcc/tree-vrp.c
--- Comment #1 from pault at gcc dot gnu dot org 2007-05-29 20:01 ---
I don't hit an ICE (Cygwin/amd64) but see a wrong result. It works fine with
anything other than logical, as long as the SIZE parameter is set to ensure
that truncation of the source data does not occur.
Confirmed
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-29 20:25 ---
Following the Steve Kargl's suggestion in
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01945.html
I have done the following test:
[archimede] test/fortran cat sec_prec_1.f90
implicit none
integer j, k, l, m, n
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-05-29 20:44 ---
Taking over.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 21:04 ---
And here is a reduced testcase:
void xfs_dir2_grow_inode(void)
{
int map;
int *mapp;
int nmap;
mapp = map;
if (nmap == 0 )
mapp = ((void *)0);
if (mapp != map)
kmem_free(mapp);
}
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-29 21:12 ---
This works for me in the 4.2 release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32142
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-29 21:14 ---
But fails on the 4.1 branch. The ICE is in GC related code (inside GCC).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I got
/export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-dfp/build-x86_64-linux/gcc/
/export/gnu/src/gcc-dfp/gcc/gcc/testsuite/gcc.dg/matrix/matrix-6.c -O3
-fipa-matrix-reorg -fdump-ipa-matrix-reorg -fwhole-program -combine
-fno-show-column -S -o matrix-6.s
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-29 21:29 ---
I get the same failure on powerpc64-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 126 matches
Mail list logo
