--- Comment #3 from steven at gcc dot gnu dot org 2005-10-03 06:14 ---
No it is not.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:24
---
This bug is now closed. I/I library support for integer(16), real(10) and
real(16) kinds is now complete. New PR should be filed if specific bugs arise
(or should I say, *when* specific bugs arise).
--
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:26
---
This bug is now closed. Front-end support for integer(16) and real(10)/real(16)
kinds is now complete. New PR should be filed if specific bugs arise (or should
I say, *when* specific bugs arise).
$ cat a.f90
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:28
---
This bug is now closed. Library support for integer(16) and real(10)/real(16)
kinds is now complete. New PR should be filed if specific bugs arise (or should
I say, *when* specific bugs arise).
--
fxcoudert
--- Comment #6 from baldrick at free dot fr 2005-10-03 08:54 ---
Subject: Re: ICE on legal (?) code: with type ... is access + variable of the
access type
with type is a GNAT extension that has been superseded by the
limited with clause introduced in the new Ada 0Y language revision.
The following program, which worked before Janne Blomqvist's recent patch to
enable array I/O, now fails:
$ cat u.f90
real(kind=10) :: a,b(1)
a = 0
b(:) = 0
print *, a
print *, b
end
$ gfortran u.f90 ./a.out
0.00
At line 5 of file u.f90
Internal Error: bad real
--- Comment #1 from jblomqvi at cc dot hut dot fi 2005-10-03 09:39 ---
Ah, yes. Also see PR22519 and PR23419. Which way do we want it for unformatted?
Should kind=10 use 10 bytes of storage or should it use whatever the padded
size is? I would prefer the padded size, as otherwise we
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-10-03 10:36
---
(In reply to comment #4)
We need to settle what kind of disk image we want for real(kind=10)
before resolving this for complex.
I am strongly in favour of real(kind=10) being written as 12 bytes on disk.
This
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-10-03 10:37
---
(In reply to comment #1)
Should kind=10 use 10 bytes of storage or should it use whatever the padded
size is? I would prefer the padded size, as otherwise we take a x10 speed hit
when doing array IO.
I do
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-03 12:12 ---
One of the reduced testcase, reduces down to PR 21592.
I will see if I can get the 3.3 reduced testcase and if that does not fail with
the 3.4/4.0/mainline, I will mark this as a dup of that bug.
--
pinskia at
--- Comment #51 from fxcoudert at gcc dot gnu dot org 2005-10-03 12:50
---
Some recent results on i686-linux:
Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental)
Using optimisation flags: -O0
CST:2 out of 4662 tests failed to pass the threshold
CST drivers
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:23 ---
Is there going to be a 3.4.5?
FWIW it would be somewhat more convenient if, say, whoever is
doing releases from 3.4 branch applied this patch. I don't have
it checked out, and going through a build is kind of a
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-03 14:26 ---
This is a duplicate.
I'm not sure what is going on with the patch in PR 23617...
*** This bug has been marked as a duplicate of 23617 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-03 14:26 ---
*** Bug 24162 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:28 ---
Ben, you can send private email about this to the folks listed
as libgcj maintainers in the gcc MAINTAINERS file, namely Bryce
and me.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-03 14:28 ---
Here is a reduced testcase for the bug effecting 2.95.3-3.4.0 but not 4.0.0 or
the mainline:
templatetypename _Tp struct _List_iterator {};
_List_iteratorint end();
templatetypename P_numtype, int N_length
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-03 14:28
---
*** Bug 24171 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-10-03 14:43
---
Hi Mark,
your patch for the 4.0 branch seems to be broken:
The ChangeLog entries are missing and it seems responsible for
heavy breakage in the testsuite, see
--- Comment #4 from uros at kss-loka dot si 2005-10-03 14:46 ---
This one looks like real RA problem to me. For some reason, global register
allocator is not allocating an xmm register to pseudo 76. This further leads to
malformed RTL pattern as shown in the original report.
There is
--- Comment #13 from mark at codesourcery dot com 2005-10-03 14:57 ---
Subject: Re: [3.4/4.0/4.1 Regression] Member function overloading
introduces syntax errors
reichelt at gcc dot gnu dot org wrote:
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-10-03 14:43
--- Comment #14 from cvs-commit at gcc dot gnu dot org 2005-10-03 15:05
---
Subject: Bug 22621
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-03 15:05:10
Modified files:
gcc/cp : ChangeLog
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-03 15:05
---
Subject: Bug 23840
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-03 15:05:10
Modified files:
gcc/cp : ChangeLog
--- Comment #4 from sje at cup dot hp dot com 2005-10-03 15:10 ---
Just to clarify the main issue here, my main concern here is not the conversion
of the for loop to a do loop but rather the alias disambiguation and the
movement of loop invariant code out of the inner most loop in
--- Comment #5 from faheem at email dot unc dot edu 2005-10-03 15:32
---
(In reply to comment #4)
Here is a reduced testcase for the bug effecting 2.95.3-3.4.0 but not 4.0.0 or
the mainline:
templatetypename _Tp struct _List_iterator {};
_List_iteratorint end();
gcc-4.1-20051003T0833UTC bootstrap fails.
(...)
make[2]: Leaving directory
`/home/users/builder/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/libcpp'
make[2]: Entering directory
`/home/users/builder/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/gcc'
true: symbol lookup error:
$ touch a.f90
$ gfortran -c a.f90
$ gfortran -c a.f90 -Wall
a.f90:0: internal compiler error: Segmentation fault
Enough said...
--
Summary: gfortran segfaults on empty source
Product: gcc
Version: 4.1.0
Status: NEW
Keywords:
Compiling this file with -O2 optimisation:
struct str {
int a, b, c, d;
};
void fct3 (struct str *);
extern inline struct str fct (void)
{
struct str returned = { 1, 2, 3, 4 };
return returned;
}
void fct2 (void)
{
struct str tmp;
tmp =
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:46 ---
This message does not make sense, it looks as your ld or as is bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24175
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:48 ---
Confirmed:
487 if (gfc_option.warn_line_truncation
488gfc_current_locus.lb-truncated)
489 gfc_warning_now (Line truncated at %C);
Looks like caused by:
2005-04-15
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-03 15:53 ---
Will look into it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:55 ---
Confirmed, this is just another case where aggregate copy prop is needed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:15 ---
A regression hunt identified this patch from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00236.html
--
janis187 at us dot ibm dot com changed:
What|Removed
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:20 ---
A regression hunt for the patch that fixed this on mainline identified the
merge of the tree-ssa branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:24 ---
A regression hunt for powerpc-linux on mainline identified the merge of the
tree-ssa branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-10-03 16:37
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-03 16:54 ---
Confirmed, reduced testcase:
void IOException( char);
inline int* dummy( const char* const mode )
{
IOException(*mode+*mode);
}
void prepare_inpaint( )
{
dummy (rb);
}
The problem is that we have rb[0] and we
--- Comment #4 from redi at gcc dot gnu dot org 2005-10-03 16:54 ---
Until DR228 the name following .template had to be a member template, so the
code would have been invalid on those grounds.
Erm, the name following .template *is* a member template, that's my whole
point! :-)
I
--- Comment #5 from redi at gcc dot gnu dot org 2005-10-03 16:56 ---
Oops, sorry, I meant:
template function call_f is dependent on include ordering and whether a
global f has been declared.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-03 17:06 ---
For what is worth Comeau rejects the code:
ComeauTest.c, line 8: error: name following template must be a member
template
t.template f int ();
^
ComeauTest.c, line 8: error: too few arguments
--- Comment #7 from mark at codesourcery dot com 2005-10-03 17:08 ---
Subject: Re: [3.4/4.0/4.1 Regression] Lookup of template member
function finds global type.
redi at gcc dot gnu dot org wrote:
--- Comment #4 from redi at gcc dot gnu dot org 2005-10-03 16:54 ---
Until
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-03 17:15 ---
Confirmed for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:18
---
Subject: Bug 17775
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-03 17:18:53
Modified files:
gcc/cp : repo.c ChangeLog
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:21
---
Subject: Bug 17775
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-03 17:21:41
Modified files:
gcc/cp : repo.c ChangeLog
gcc/testsuite :
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-03 17:23
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:30
---
Subject: Bug 24127
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-03 17:30:38
Modified files:
gcc/java : ChangeLog parse.y
Log message:
PR
--- Comment #3 from rmathew at gcc dot gnu dot org 2005-10-03 17:31 ---
Fix checked in.
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-03 17:44 ---
I can reproduce this reliably for powerpc64-linux with -m64 using the testcase
in comment #3; using -m32 the results are intermittent.
A regression hunt identified the following patch from [EMAIL PROTECTED]:
--- Comment #8 from redi at gcc dot gnu dot org 2005-10-03 17:54 ---
Aah, gotcha. I now see why the global scope has to be considered, and why
DR228 is relevant. Thanks! I still think it's of dubious value having the
standard defined like that, so might take it to the UK panel and
--- Comment #24 from rguenth at gcc dot gnu dot org 2005-10-03 17:54
---
It somehow works (partially), but there's a lot of fallout. Ugh. I don't like
it very much. Preliminary patch:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00091.html
--
janis187 at us dot ibm dot com [EMAIL PROTECTED] writes:
| A regression hunt for the patch that fixed this on mainline identified the
| merge of the tree-ssa branch.
Thanks. That would indicate that if we're unable to find a minimal
patch, then we would just have to close it as WONTFIX.
--
--- Comment #3 from gdr at integrable-solutions dot net 2005-10-03 18:16
---
Subject: Re: [3.4 Regression] ICE in simple_cst_equal
janis187 at us dot ibm dot com [EMAIL PROTECTED] writes:
| A regression hunt for the patch that fixed this on mainline identified the
| merge of the
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
gcc version 4.0.2
GNU C version 4.1.0 20050927 (experimental) (alpha-unknown-linux-gnu)
All tested versions generate the same wrong code for the following testcase
(EV4/EV5 only with -O2 optimization):
#include stdio.h
#include stddef.h
typedef struct
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 19:03 ---
I think you are violating some alignment rule in C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 19:07
---
Subject: Bug 24057
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-03 19:07:10
Modified files:
libjava/classpath: ChangeLog.gcj
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
--- Comment #5 from tromey at gcc dot gnu dot org 2005-10-03 19:08 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jblomqvi at cc dot hut dot fi 2005-10-03 19:37 ---
Created an attachment (id=9865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9865action=view)
Patch for PR24174, also fixes formatted output for complex(10)
libgfortran Changelog:
2005-10-03 Janne Blomqvist
The following FORTRAN source crashes the gfortran 4.02 compiler when using the
-fdefault-integer-8 option
logical function junk(num,isat)
implicit none
c
character*2 pre_atnam
external pre_atnam
integer num(*),isat(*)
c
write(6,*) pre_atnam(num(isat(3)))
--- Comment #4 from jblomqvi at cc dot hut dot fi 2005-10-03 19:40 ---
Created an attachment (id=9866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9866action=view)
Testcase
And here is a test case to go with the previous patch.
Sorry my mail is b0rked at the moment so I can't
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 19:43 ---
*** This bug has been marked as a duplicate of 20971 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-03 19:43 ---
*** Bug 24179 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from falk at debian dot org 2005-10-03 20:48 ---
(In reply to comment #0)
The offset of p5 member is 25 bytes, but compiler thinks that p5 is
aligned
in foo function
You are casting a pointer to a Foo* that doesn't have proper alignment for
a Foo. This is undefined
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-03 20:57
---
Subject: Bug 24135
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-03 20:57:45
Modified files:
gcc: ChangeLog tree-nested.c
Added files:
The following code is rejected even though it should not be:
#import objc/Object.h
union a { id g; };
void f(union a);
void g(Object *b)
{
f((union a)b);
}
-
Object* should be able to goto id without any troubles.
--
Summary: [4.1 Regression] rejects union cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 21:14 ---
Forgot to say this shows up while compiling GNUStep.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24180
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-03 21:30 ---
The code is invalid, the related C testcase:
union a { void *g; };
void f(union a);
void g(int *b)
{
f((union a)b);
}
Which is rejected everywhere.
--
pinskia at gcc dot gnu dot org changed:
What
Testing
--
Summary: testing (please ignore)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: spam
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 21:32 ---
Please ignore.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-03 21:59 ---
A regression hunt using the testcase from comment #3 identified this patch from
[EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00624.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24172
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 22:02
---
Subject: Bug 24135
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-03 22:01:55
Modified files:
gcc: ChangeLog
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-03 22:05 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-03 22:26 ---
A regression hunt using an i686-linux cross compiler with the testcase from
comment #3 identifies this patch from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00534.html
That doesn't fit with the
--- Comment #3 from kkojima at gcc dot gnu dot org 2005-10-03 22:28 ---
This PR was discussed at the thread of gcc-patches list statring
with http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01527.html and
Joern pointed out that we must improve the reload infrastrucure to
fix this PR.
If you touch standard.omit.in, 'make' won't rebuild
standard.omit -- the file is only created by configure,
and not via AC_OUTPUT.
--
Summary: standard.omit not properly rebuilt
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity:
The native xmlj code in classpath is not properly built for
libgcj. We most likely need to link the JNI code into whatever library
contains the java code; the xmlj code will need the standard loadLibrary
tweak for this to work properly.
--
Summary: xmlj code not properly built
--- Comment #5 from kkojima at gcc dot gnu dot org 2005-10-03 23:13 ---
Joern has analyzed this PR in
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01654.html
and pointed out that it's a middle-end issue.
--
kkojima at gcc dot gnu dot org changed:
What|Removed
Compilation of gnu/CORBA/DynAny/gnuDynValue to bytecode
has a bug. The resulting equal() method has this in it:
61: invokespecial #193=InterfaceMethod org.omg.DynamicAny.DynAny.equal
(org.omg.DynamicAny.DynAny)boolean
However, DynAny is an interface. The corresponding source code
is a call
FAIL: gcc.dg/vect/vect-shift-1.c execution test
has appeared on mainline on ia64-hp-hpux11.23 between 20051001 and 20051003.
This is a new test added between those test runs.
--
Summary: gcc.dg/vect/vect-shift-1.c execution test fails
Product: gcc
Version
interface a
{
void f();
}
class b
{
void f(){}
}
class d extends b implements a
{
void f(){}
static public void main(String args[])
{
d eee = new d();
eee.f();
}
}
--
Summary: interface and extends does not cause us to reject
invalid code
--- Comment #6 from bangerth at dealii dot org 2005-10-04 02:03 ---
Confirmed. A redux is here:
--
templatetypename T
struct O {
struct I;
};
template
struct Oint::I
{
I();
};
Oint::I::I() {}
--
g/x
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 02:11 ---
: Search converges between 2004-07-20-trunk (#491) and 2004-07-21-trunk (#492).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-04 02:17 ---
This looks like it was introduced by the fix for PR 14497.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-04 02:31 ---
Fixed by:
* error.c (dump_type) UNKNOWN_TYPE: Print reworded message.
* g++.dg/overload/unknown1.C: New.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 02:31 ---
Fixed by:
Fixed by:
* error.c (dump_type) UNKNOWN_TYPE: Print reworded message.
* g++.dg/overload/unknown1.C: New.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-04 02:32 ---
The error message was changed by:
Fixed by:
* error.c (dump_type) UNKNOWN_TYPE: Print reworded message.
* g++.dg/overload/unknown1.C: New.
But reading comment 4, that will not fix the issue fully.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-04 02:41 ---
Fixed by:
2005-10-01 Richard Henderson [EMAIL PROTECTED]
* tree-stdarg.c (execute_optimize_stdarg): Process PHI nodes too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-10-04 02:43
---
I am going to fix this tonight.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-04 03:02
---
Subject: Bug 23445
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-04 03:02:20
Modified files:
gcc: ChangeLog tree-vrp.c
gcc/testsuite :
--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-10-04 03:05
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00117.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-04 03:05
---
Created an attachment (id=9867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9867action=view)
Patch which I am testing
This is the correct version of your patch which does not effect AIX or
PPC64-linux
--- Comment #32 from cvs-commit at gcc dot gnu dot org 2005-10-04 05:57
---
Subject: Bug 23049
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-04 05:57:38
Modified files:
gcc: ChangeLog tree-ssa-dom.c
gcc/doc
--- Comment #3 from tsv at solvo dot ru 2005-10-04 05:59 ---
(In reply to comment #2)
(In reply to comment #0)
The offset of p5 member is 25 bytes, but compiler thinks that p5 is
aligned
in foo function
You are casting a pointer to a Foo* that doesn't have proper alignment
93 matches
Mail list logo
