--- Comment #53 from ebotcazou at gcc dot gnu dot org 2008-03-30 09:15
---
I should have been more careful, there are wrong premises:
Yes. Amazing, isn't it ;) The important thing to keep in mind is that
all target variables must be in the range 10..20, and all source
variables
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:24 ---
This is tightly coupled to libstdc++/35353: in the current design, when
sync_with_stdio is false (by default), the stream is non-converting and synced
with C stdio, simply forwards to stdio functions. Unfortunately, the
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:27 ---
Really, this is a WORKSFORME, code in Comment #2 is fine everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-30 12:40 ---
This one should be straightforward, if lengthy to correct:
gfc_trans_where_2 is completely correct, as can be verified by doubling up the
line making the assignment in the WHERE block. ie:
WHERE (LDA)
As I understand the gfortran docs, the -ff2c/-fno-f2c switches change how
functions returning complex numbers are implemented:
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it (can be seen e. g. in
http://www.pgroup.com/doc/pvfug.pdf, chapter
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 13:34
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 13:40 ---
CLOSED AS INVALID.
return type of complex functions not C compatible
While (with the default options) Fortran should be compatible with C in this
case, the proper way would be to use Fortran 2003's BIND(C)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 13:51 ---
-ff2c: the return value is returned in an additional argument as g77 and other
fortran compilers do it
I want to point out that all? modern compiler use the -fno-f2c scheme which is
compatible with the default
In C++, when theres a class with multiple inheritance and one wants to cast a
pointer to it to the type of a base class which is not the first in the list,
like in this code:
class D: public B1, B2 { . . . };
D* d = get_some_D_possibly_NULL();
B2* b = d;
the pointer must be offset according to
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-30 14:14 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:13:21 2008
New Revision: 133729
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133729
Log:
2008-03-30 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #54 from baldrick at gcc dot gnu dot org 2008-03-30 14:14
---
Here's a test that VRP is not eliminating
validity checks. abort should be called
if either X or Y is = 0. With Richard's
latest patch (from the gcc mailing list)
applied, everything is fine: the tests are
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
function Overflow (X :
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-30 14:23 ---
Subject: Bug 35740
Author: pault
Date: Sun Mar 30 14:23:10 2008
New Revision: 133730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133730
Log:
2008-03-30 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-30 14:25 ---
Fixed on trunk and 4.3. Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #56 from baldrick at free dot fr 2008-03-30 14:26 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
What does must be in the range mean? Firstly, the program behaviour is
undefined if a variable is outside its range.
That's not true. The reference
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-30 14:45
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #57 from rguenther at suse dot de 2008-03-30 14:52 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, baldrick at gcc dot gnu dot org wrote:
--- Comment #55 from baldrick at gcc dot gnu dot org 2008-03-30 14:18
---
And
--- Comment #58 from rguenth at gcc dot gnu dot org 2008-03-30 14:55
---
Btw, can we have those testcases in gnat.dg/ with a name I can remember
(bounds-N.adb or similar)? Looking for testcases in acats is no fun ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-30 14:57 ---
Subject: Bug 31023
Author: rguenth
Date: Sun Mar 30 14:56:28 2008
New Revision: 133731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133731
Log:
2008-03-30 Richard Guenther [EMAIL PROTECTED]
PR
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #59 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:03
---
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is failing
to generate checks at all!
Even with -gnato?
--- Comment #60 from rguenth at gcc dot gnu dot org 2008-03-30 15:09
---
function overflow (x : positive) return integer is
y : positive;
a : static array (1 .. 16#7FFF_#) of integer;
pragma import (ada, a);
begin
R4b : constant long_long_integer := long_long_integer?(a
--- Comment #61 from baldrick at free dot fr 2008-03-30 15:16 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
And here's a testcase that was supposed to check that
VRP is not removing checks that array accesses are in
range. Instead it shows that the Ada f-e is
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 15:33 ---
I also see this failure on powerpc-darwin after changing MOVE_RATIO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
Yes, even with -gnato. With -gnato it checks that the
addition doesn't overflow.
Oh, sorry, I thought we were talking about the overflow check...
But there are no checks on the array access. It looks like
--- Comment #63 from rguenther at suse dot de 2008-03-30 15:56 ---
Subject: Re: VRP fails to eliminate range checks
in Ada code
On Sun, 30 Mar 2008, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #62 from ebotcazou at gcc dot gnu dot org 2008-03-30 15:45
---
Yes,
--- Comment #64 from baldrick at free dot fr 2008-03-30 16:02 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
But there are no checks on the array access. It looks like the f-e
doesn't generate them in the first place (as opposed to fold or gigi
making a
--- Comment #65 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:15
---
So even GNAT assumes parameter values are in-range? Wouldn't that
cause an bounded error to become an unbounded error if it were
out-of-range?
GNAT considers that it's an unbounded error in a few specific
--- Comment #66 from ebotcazou at gcc dot gnu dot org 2008-03-30 16:18
---
Consider the following test case:
procedure Overflow (X : Positive) return Integer is
A : array (Positive) of Integer;
pragma Import (Ada, A);
begin
A (X) := X;
end;
(for which no checks are
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-03-30 16:36 ---
Related program, which also fails (I thought we fixed this; this seems to be a
libgfortran problem):
integer xda(20)
integer, volatile :: n
n = 1
print *, size(XDA(n:2:-3)) ! should
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128 __attribute__((noinline))
iszero (__m128 x)
{
return x;
}
typedef __m128 __attribute__((aligned(1))) unaligned;
__m128 __attribute__((noinline))
foo (__m128 a1, __m128 a2, __m128 a3, __m128
--- Comment #67 from baldrick at free dot fr 2008-03-30 17:03 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
Try first to compile it. :-)
I did! I didn't notice the compile error
after the -gnatG output. Indeed, when fixed
thusly
procedure Overflow (X :
This is the cutest web site I've ever seen. It has puppies, miniature
schnauzers!
If you like dogs, take a look at this site. I'm posting this web site to
this group for my friends to get. Sorry if you got it and didn't want it.
I'm trying to get my friend in Germany this web site.
Executing on host: /home/dave/gnu/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.4/objdir/gcc/ -O0 -w -fno-show-column -c -o
20010226-1.o /home/dave/gnu/gcc
-4.4/gcc/gcc/testsuite/gcc.c-torture/compile/20010226-1.c(timeout = 300)
--- Comment #14 from dje at gcc dot gnu dot org 2008-03-30 19:31 ---
Any progress on the regressions caused by the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
--
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=34040
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-30 20:00 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-24 17:07:47 |2008-03-30
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-30 20:04 ---
This works for me and many others so closing as worksforme.
--
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.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35019
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
This works for me with 4.2.0, 4.3.0 and the trunk on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:12 ---
I see them also on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:19 ---
Using a sysroot or setting --prefix for both the newlib build and the GCC build
is the easiest way of getting a cross build to work.
Anyways here are the options I use to build a cross build for spu:
stage1
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-30 20:26
---
Closing as invalid. Just like any other linking of shared libraries, you need
the correct LD_LIBRARY_PATH set or use static library versions.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-30 20:28 ---
What do you mean by preprocessed source.?
Please http://gcc.gnu.org/bugs.html which explains that.
Also it might be best if you try a newer version of GCC since 3.4.x is no
longer being maintained.
--
pinskia
--
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=35706
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-30 20:42 ---
I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it comes to pointers to
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-30 20:45 ---
With -Wextra (aka -W), we get a warning now:
t.cc:1: warning: type qualifiers ignored on function return type
So closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
The following (silly) program gives an incorrect error message.
There is only one assignment to each diagonal element of
the array. I don't feel strongly about this because FORALL
is sort of a junk feature and this is an unlikely programming
style. But, to be correct you should downgrade from
--- Comment #3 from Georg dot Baum at post dot rwth-aachen dot de
2008-03-30 20:48 ---
Thanks for the quick reply. You where right, I mixed up the FF2C macro in the
test case. Unfortunately this was not the real problem. The problem I had in my
code was that calling BLAS zdotc from C++
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:54 ---
Confirmed, it has been failing since at least 4.2.0 20061019 .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:56 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 20:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 21:08 ---
Confirmed, as noted by Uros, you should submit the patch to [EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The program gives an error message when the internal
function has an apparent character type due to the implicit
statement. Commenting out the implicit fixes it. This
looks similar to 34784 to me.
program SA0021
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35611
--- Comment #3 from hjl at gcc dot gnu dot org 2008-03-30 21:14 ---
Subject: Bug 35757
Author: hjl
Date: Sun Mar 30 21:13:33 2008
New Revision: 133736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133736
Log:
gcc/
2008-03-30 H.J. Lu [EMAIL PROTECTED]
PR target/35757
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-30 21:18 ---
Not all. I gave two counter examples: pvf and ifort.
Well at least ifort 9.1, 10.0 and 10.1 on Linux do not use the f2c calling
convention. Neither does NAG f95. But I agree that _ vs __ and different
calling
--- Comment #3 from petrosyan at gmail dot com 2008-03-30 21:23 ---
I posted the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01639.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:27 ---
Confirm. I agree that it is valid (although bad style) code.
I think there should be no warning printed if a index-name is used in the
scalar-mask-expr. Otherwise, if it is neither used in the scalar-mask-expr nor
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-30 21:28 ---
The updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01916.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-30 21:38 ---
(In reply to comment #1)
Note: PR 34784 contains a failure which was missed.
Actually, the test case in PR 34784, comment 8 now passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35770
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-30 21:34 ---
Confirm. Implicit typing is too fast. It is quite similar to PR 34784.
Note: PR 34784 contains a failure which was missed.
A procedure question. Is this the One True Way to add additional
comments or tests
--- Comment #9 from burnus at gcc dot gnu dot org 2008-03-30 21:37 ---
(reply to comment #8)
I have another example of what might be the same problem, although the
symptoms are a little different.
This test case seems to work meanwhile (both in gfortran 4.3.0 and 4.4.0, it
fails in
--- Comment #10 from kst at mib dot org 2008-03-30 21:49 ---
(In reply to comment #9)
I'd expect the warning to be muted in one of the calls, depending on
-f{un}signed-char.
No, char is a seperate type from signed char and unsigned char so they are
always incompatiable when it
--- Comment #6 from schwab at suse dot de 2008-03-30 21:58 ---
Fixed.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-30 21:59
---
Subject: Bug 35748
Author: reichelt
Date: Sun Mar 30 21:58:43 2008
New Revision: 133737
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133737
Log:
PR c/35748
* c-typeck.c (build_c_cast):
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:02
---
Subject: Bug 35578
Author: reichelt
Date: Sun Mar 30 22:02:06 2008
New Revision: 133738
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133738
Log:
PR c++/35578
* parser.c
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-30 22:04 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-03-30 22:08
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 22:09
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Call expander ignores type alignment. But caller honors type alignment.
It usually isn't a problem until the argument is passed via stack. We
have a mismatch between caller and callee:
bash-3.2$ cat x.c
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
__m128
GCC compiles the code below without any error:
//--
class A {
protected:
virtual void foo() const = 0;
};
// Defining pure virtual functions should not be allowed.
void A::foo() const
{
}
//--
--
Summary: GCC allows
--- Comment #3 from yuriry at gmail dot com 2008-03-30 22:29 ---
I believe that the main problem here is that GCC allows defining pure virtual
functions. The compiler should report an error when these two functions are
defined:
//
void
--- Comment #3 from schwab at suse dot de 2008-03-30 22:36 ---
Not a bug.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #15 from eric dot weddington at atmel dot com 2008-03-30 22:40
---
FWIW, test case passes for avr-*-* target version 4.3.0 -O[0123s]
-frtl-abstract-sequences
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #2 from schwab at suse dot de 2008-03-30 22:41 ---
Not reproducible, assuming fixed.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2008-03-30 22:44 ---
*** Bug 35454 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from schwab at suse dot de 2008-03-30 22:44 ---
*** This bug has been marked as a duplicate of 32424 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #5 from schwab at suse dot de 2008-03-30 22:49 ---
No longer reproducible on the trunk.
--
schwab at suse dot de changed:
What|Removed |Added
Known to
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-30 23:21 ---
Subject: Bug 35245
Author: danglin
Date: Sun Mar 30 23:20:57 2008
New Revision: 133739
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133739
Log:
PR c++/35245
* g++.dg/other/anon5.C: Skip on
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-30 23:24 ---
Subject: Bug 35245
Author: danglin
Date: Sun Mar 30 23:23:43 2008
New Revision: 133740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133740
Log:
PR c++/35245
* g++.dg/other/anon5.C: Skip on
--- Comment #3 from danglin at gcc dot gnu dot org 2008-03-30 23:30 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 23:31 ---
This is now fixed:
add_tri:
fa $3,$3,$6
stqd$sp,-224($sp)
fa $4,$4,$7
fa $5,$5,$8
ai $sp,$sp,-224
lnop
ai $sp,$sp,224
bi
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-30 23:58 ---
The problem is __m128 shoulbn't the canonical type for unaligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35771
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-30 23:58 ---
(gdb) p debug_rtx (rl-out)
(scratch)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35768
--- Comment #2 from danglin at gcc dot gnu dot org 2008-03-31 00:03 ---
Richard, does match_scratch now require a mode? The pattern causing
the problem was written without a mode so that it could handle both
SImode and DImode.
--
danglin at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-31 00:16 ---
So what is happening is we are not applying the attribute while doing overload
resolution so we reject the template function then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-31 00:18 ---
That being said, I think fn_type_unification should apply the attributes but I
don't know/understand the template part of the C++ front-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-31 02:04 ---
useless_type_conversion_p returns true for
(gdb) call debug_tree (outer_type)
vector_type 0x2ac11240 unaligned
type real_type 0x2ab0a6c0 float asm_written SF
size integer_cst 0x2aaeba80
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-31 04:46 ---
*** Bug 35771 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35767
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-31 04:46 ---
*** This bug has been marked as a duplicate of 35767 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-31 04:48 ---
Middle end use canonical type for passing parameters to function
calls. ix86_function_arg_boundary should do the same. Otherwise,
there will be a mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35767
100 matches
Mail list logo
