--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
FIXED on the trunk (4.5).
Patch was: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01147.html
See also follow-up PR 40452.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from burnus at gcc dot gnu dot org 2009-06-16 06:57 ---
Subject: Bug 40383
Author: burnus
Date: Tue Jun 16 06:57:09 2009
New Revision: 148517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148517
Log:
2009-06-16 Tobias Burnus
PR fortran/40383
*
--- Comment #104 from bonzini at gnu dot org 2009-06-16 06:47 ---
I understood that with -frename-registers the regression is fixed. As I said,
without a pre-regalloc scheduling pass and without register renaming, the
scheduling quality you get is more or less random.
--
http://gcc
As of commit r148408, http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00388.html, gcc
trunk does not bootstrap on cygwin using configure like this:
../gcc/configure --enable-threads=posix --enable-libgcj
--disable-sjlj-exceptions --with-system-zlib --enable-nls --enable-static
--enable-shared --enable-sh
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-16 04:30 ---
All regressions are caused by revision 148442, including
gcc.dg/func-ptr-conv-1.c. You may need to enable checking
to see it.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-16 03:56 ---
ping 4.3.4...
The PR40087 fix depends on changes from the this fix, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
--- Comment #13 from cnstar9988 at gmail dot com 2009-06-16 03:54 ---
ping 4.3.4...
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #23 from mrsam at courier-mta dot com 2009-06-16 03:51 ---
Created an attachment (id=18004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18004&action=view)
Revised patch
Well, this is approximately what I have in mind. Aside from the formatting
style, which I can clea
--- Comment #5 from hp at gcc dot gnu dot org 2009-06-16 02:36 ---
To add something useful, I should have mentioned that they were ok for 148440,
regressed for 148444 for cris-elf, so that leaves only commit's from Aldy and
Steven B., IIUC.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from hp at gcc dot gnu dot org 2009-06-16 02:28 ---
Mee too! I mean, seen for cris-elf too!
BTW, isn't it odd that for recent regressions, the committer's testing never
seem to have shown the regressions seen by "every other target" after commit?
1/2 ;)
(Definitely _not_
Hi,
I notice that PNGCrush compiled with GCC 4.4.0 (release) is about 20% slower
compared to GCC 3.4.0 build. (Amiga 68...@50mhz).
CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s
PNGCrush test.png out.png
Here are the results:
GCC 3.4.0 build:
CPU time used = 267.340 sec
--- Comment #22 from paolo dot carlini at oracle dot com 2009-06-15 23:14
---
A patch would help understanding what you exactly mean, at the moment, I'm
skeptical.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #21 from peturrun at gmail dot com 2009-06-15 23:10 ---
Isn't it possible to add more data to messages without breaking the ABI by
changing the type of one of the existing members?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #14 from dje at gcc dot gnu dot org 2009-06-15 23:06 ---
This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE
finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the
REG_NOTE on the move itself share RTL.
I suspect we need to app
Follow up to PR 36947/PR 40039. I think there was no PR yet, if not -> mark as
duplicate. See also PR 40276.
I think some other checks should still be added, e.g.
a) PUREness check (see example below); passing/assigning
a pure to a non-pure dummy/proc-pointer is OK; doing vice versa
is no
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-15 22:40 ---
Also for OPTIONAL a suitable error message would be useful. For finding a
specific interface, the OPTIONAL attribute could be ignored similarly to
INTENT; however, one needs to be careful as for ambiguity checks and i
--- Comment #20 from paolo dot carlini at oracle dot com 2009-06-15 22:18
---
One last clarification, maybe necessary because not spelled out (yet) in the
docs: really, when we say *ABI* we mean it in a very wide sense, also including
linking together objects built with different versio
--- Comment #19 from paolo dot carlini at oracle dot com 2009-06-15 22:06
---
I think we are definitely going to wait for the next ABI, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #18 from mrsam at courier-mta dot com 2009-06-15 21:53 ---
Yes, the patch does add a new data member to the class. I see that this would
fall under item #8 under "prohibited changes", although, as I said, AFAIK it
won't actually break binary compatibility with existing applic
Follow up to PR 37746 / PR 40383. I believe the following program is valid due
to the storage association/argument association. However, with -fcheck=bounds
one gets:
At line 5 of file aa.f90
Fortran runtime error: Actual string length is shorter than the declared one
for dummy argument 'a' (2/4)
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 21:10 ---
Post script: With your current patch, the error message is:
Error: Interface mismatch in procedure pointer assignment at (1): 'sin' has the
wrong number of arguments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
The following program is rejected with:
f => sin
1
Error: Interfaces don't match in procedure pointer assignment at (1)
However, if one removes the "module m; contains" it is accepted
module m
contains
function f()
intrinsic :: sin
procedure(sin), pointer :: f
f => si
--- Comment #3 from geir at cray dot com 2009-06-15 20:47 ---
For another point of reference, I see this problem in our GCC 4.3.1 build; but
the problem did not occur in our gcc 4.3.0 and 4.3.2 versions. I assume this
was an error on our part.
$ diff
/opt/gcc/4.3.1/snos/lib/gcc/x86_64-
--- Comment #103 from lucier at math dot purdue dot edu 2009-06-15 20:21
---
Regarding comment #101 ...
With
heine:~/programs/gcc/objdirs/gsc-fft-tests/gambc-v4_1_2>
/pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline/co
--- Comment #102 from lucier at math dot purdue dot edu 2009-06-15 19:57
---
Subject: Re: [4.3/4.4/4.5 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Mon, 2009-06-15 at 16:20 +, paolo dot bonzini at gmail dot com
wrote:
> Yes, and the output of
--- Comment #3 from gni at gecko dot de 2009-06-15 19:36 ---
Subject: gcc 4.4.0 error at postreload.c:396
(In reply to comment #2)
> Could be a duplicate of one of PR30064, PR34439, PR37053.
I compiled the provided testcases as stated in the appropriate PR
with the following result:
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:45
---
I'm not sure it's still present: if I look into the 10.3.9 and the 10.4u
headers, I see:
#ifdef __cplusplus
Class super_class;
#else
Class class;
#endif
The 10.5 header is very different, but i
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-15 18:44 ---
(In reply to comment #3)
> This is not darwin-specific, I also see it happening on x86_64-linux.
>
> And what's more, the output changes between -m32 and -m64.
The code is invalid Fortran, so gfortran is not required
The following program gives a segfault at runtime:
MODULE m
ABSTRACT INTERFACE
SUBROUTINE sub()
END SUBROUTINE sub
END INTERFACE
CONTAINS
SUBROUTINE passf(f)
PROCEDURE(sub), POINTER:: f
CALL callf(f)
END SUBROUTINE passf
SUBROUTINE callf(f)
PROCEDURE(sub), POINTER :: f
PRINT
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:32
---
This is not darwin-specific, I also see it happening on x86_64-linux.
And what's more, the output changes between -m32 and -m64.
$ cat u.f90
integer(8), parameter :: l = z'5fe6eb3be000'
integer, parameter ::
--- Comment #3 from ksong at lbl dot gov 2009-06-15 18:21 ---
(In reply to comment #1)
> You need to install the 32bit userland.
Thanks for your response. I am not familiar with 32 bit userland. Can you give
me more instructions, or links that I can learn more about it?
Thanks.
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target t
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:17
---
Without any more information, there's nothing we can do. I tried to reproduce
with a simple testcase, but I can't.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 ---
*** Bug 40449 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 ---
*** This bug has been marked as a duplicate of 40448 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Dear GUN team,
I came across the following error when I try to compile gcc4.04:
/usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when sear
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 17:57 ---
You need to install the 32bit userland.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Dear GUN team,
I came across the following error when I try to compile gcc4.04:
/usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when sear
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-15 17:20 ---
Has been true since:
r124822 | ghazi | 2007-05-17 19:04:02 -0700 (Thu, 17 May 2007) | 3 lines
* toplev.c (print_version): Output GMP/MPFR version info.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=404
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-15 17:19
---
Older versions show the information too:
$ echo | gcc -v -x c -c - 2>&1 | fgrep -B1 GMP
GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.3, MPFR version 2.3.1
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-15 17:08 ---
Subject: Bug 40426
Author: jakub
Date: Mon Jun 15 17:08:02 2009
New Revision: 148497
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148497
Log:
PR testsuite/40426
* lib/gcc-dg.exp (gcc-dg-debug
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-15 16:56
---
I assume this is only in your experimental version. I can see that is an
improvement. I still think the switch would be useful, but it does reduce the
need for it somewhat.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-15 16:53 ---
GCC already outputs the version of GMP/MPFR:
GNU C (GCC) version 4.5.0 20090519 (experimental) [trunk revision 147718]
(i386-apple-darwin8.11.1)
compiled by GNU C version 4.5.0 20090519 (experimental) [trunk
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-15 16:52
---
That's what I did.
The real benefit I see is that someone could see what versions of the gmp and
mpfr were used to configure gcc. So if they wanted to build it the same, they
would have a much better chance. I
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-06-15
16:51 ---
Subject: Re: O32 libgfortran.so fails to link on IRIX 6.5
rwild at gcc dot gnu dot org writes:
> Would it help to work around this issue by collecting the objects in one or
> more
> convenience archives a
--- Comment #108 from bonzini at gnu dot org 2009-06-15 16:30 ---
http://gcc.gnu.org/bugzilla/attachment.cgi?id=17968
This is the current state of -ftime-report/-fmem-report after the proposed
reimplementation of fwprop's dataflow.
Remaining hogs are:
1) Accounting for TV_ALIAS_STMT_WA
--- Comment #101 from bonzini at gnu dot org 2009-06-15 16:26 ---
Time for cleanup. This bug is fixed on mainline, and likely WONTFIX on 4.3/4.4
(though it could in principle be fixed by backporting the fwprop patches to
4.4). I'll add some pointers to PR26854 for the attachments relat
--- Comment #4 from bonzini at gnu dot org 2009-06-15 16:26 ---
Someone can please check if this is still a problem in 4.5?
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #100 from bonzini at gnu dot org 2009-06-15 16:22 ---
Just as a reminder for after the fwprop patches are committed, the problem in
CFG cleanup is that the iterative fixing of dominators in
remove_edge_and_dominated_blocks is very expensive. Probably we should make
sure no d
--- Comment #99 from paolo dot bonzini at gmail dot com 2009-06-15 16:20
---
Subject: Re: [4.3/4.4/4.5 Regression] 30% performance
slowdown in floating-point code caused by r118475
> First, I've applied your patches to speed up computing DF to my tree; do you
> want them included in
--- Comment #98 from lucier at math dot purdue dot edu 2009-06-15 16:11
---
I don't quite understand how you would like me to configure and run the test.
First, I've applied your patches to speed up computing DF to my tree; do you
want them included in the test, or should I use a prist
--- Comment #2 from rwild at gcc dot gnu dot org 2009-06-15 16:11 ---
Would it help to work around this issue by collecting the objects in one or
more
convenience archives and linking those (plus at least one plain object)
together
to form libgfortran.la? The intermediate partially link
--- Comment #1 from aph at gcc dot gnu dot org 2009-06-15 15:47 ---
Adding Andreas Tobler; perhaps he knows.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #97 from bonzini at gnu dot org 2009-06-15 15:14 ---
Brad, could you try to time compiler.i with and without -ftime-report to see
how much of the "tree stmt walking" timevar is just accounting overhead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 15:00 ---
(In reply to comment #1)
> Why is this a regression? Do we support _builtin_unreachable() in 4.4?
Well it is a regression as it compiled before and did not do what the user
expected though.
--
pinskia at gcc dot
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-15 14:59 ---
Why is this a regression? Do we support _builtin_unreachable() in 4.4?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 14:59 ---
You can use soft links inside the source directory to say where the source
directories are located. Is that good enough?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 14:55 ---
(In reply to comment #1)
> Caused by
> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134947
In this case, exposed as VIEW_CONVERT_EXPR was not widely used before so there
will be some bugs that we did not hit unt
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-15 14:35 ---
Caused by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134947
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
--- Comment #15 from mikpe at it dot uu dot se 2009-06-15 14:24 ---
(In reply to comment #14)
> ping 4.3.4...
The PR40087 fix depends on changes from the PR39455 fix. Both of them are 4.3
regressions, and I've used both fixes in my 4.3 tree for a while now without
issues.
--
http:/
It's currently possible to build gcc in two ways.
1) Compiler and install mpfr and use switches to indicate the location of their
instalation
--with-mpfr=/somedirector --
2) Put directories mpfr and gmp under the source of gcc.
What I propose is to allow a couple of extra switches
--mpfr-sour
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|g++ void f() {|[4.5 Regression] g++ void
|__builtin_unreachable(
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
#include
#include
#include
int
main ()
{
union { __m128d vec; double val[2]; } u;
std::complex c = std::complex(0, 1);
u.vec = _mm_load_pd ((double*)&c);
if (u.val[0] != 0 || u.val[1] != 1)
abort ();
}
ICEs with -O1 and above in g++ 4.4 and above. More reduced testcase:
struct S
{
--- Comment #16 from eres at il dot ibm dot com 2009-06-15 13:32 ---
> -/* { dg-final { scan-tree-dump-times "Alignment of access forced using
> versioning" 3 "vect" { target { vect_no_align || { { !
> vector_alignment_reachable} && {!vect_hw_misalign} } } } } } */
> +/* { dg-final { sca
--- Comment #4 from pault at gcc dot gnu dot org 2009-06-15 13:21 ---
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.
Well, gosh golly, that's a mantle that I did not seek:-)
Note that my account at the CC address is no longer valid - I'll fix that.
Compiling the single line program
void f() { __builtin_unreachable(); }
works fine with gcc, but triggers an ICE when compiled with g++
unreachable.c:1:37: internal compiler error: in remove_insn, at emit-rtl.c:3796
I'm using SVN revision 148487.
--
Summary: g++ void f() { __bui
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-15 13:09 ---
Juergen: Thanks for the report, but it is not a regression - it might not crash
with 4.3 (or your 4.4) but I think that's just by chance.
Paul, I think also this bug touches code for which you have the expertise.
Th
--- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> --- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
> (In reply to comment
--- Comment #15 from dominiq at lps dot ens dot fr 2009-06-15 12:46 ---
With the patch in comment #14, on i686-apple-darwin9 I get:
=== gcc tests ===
Schedule of variations:
unix
unix/-m64
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board
--- Comment #14 from dominiq at lps dot ens dot fr 2009-06-15 12:36 ---
(In reply to comment #13)
> if that still does not fix the problem I will try to add more braces...
I tried several variants that were not working. The following patch works,
though I have no idea if it is right:
[
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-15 12:16 ---
Note: syntax_get_rule_ptr is defined as:
function syntax_get_rule_ptr (syntax, key) result (rule)
type(syntax_rule_t), pointer :: rule
type(syntax_t), intent(in), target :: syntax
type(string_t), intent
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-15 12:06
---
8.3.5p5? is that reference right?
and I assume you mean line 10, not line 14.
The pair(pair&&) constructor is not in the WP. Commenting it out causes the
pair(pair&&) constructor to be used, which fails to compil
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
> If you have modified the implementation (by putting headers/libraries in
> standard directories where those headers/libraries were not provided by
> the implementation in those versions in tho
--- Comment #17 from paolo dot carlini at oracle dot com 2009-06-15 11:36
---
Maybe it's because I didn't really look carefully at the patch: aren't you
adding a new data member to the class? Changing either size or layout of a type
specified in the C++ standard definitely changes the A
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 11:24 ---
> > gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> > print the following:
Correction, ifort 9.1 to 11.1 all print "S, S" - sorry for missing it. But the
other compilers listed above ind
--- Comment #16 from mrsam at courier-mta dot com 2009-06-15 11:13 ---
After staring at the code for a while, I'm leaning towards thinking that this
change does not really change the application ABI, so the soname bump is not
needed.
As far as I can tell, there are no public members of
--- Comment #3 from joseph at codesourcery dot com 2009-06-15 10:57 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> This may be true for standard headers, but system directories don't contain
> only standard header
--- Comment #13 from eres at il dot ibm dot com 2009-06-15 10:41 ---
Created an attachment (id=18003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18003&action=view)
Patch to fix error in vect-42.c
Ira, thanks for the suggestion!
I deleted an extra space, so now the syntax is {!
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-15 10:10 ---
ping 4.3.4...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 ---
Subject: Bug 40439
Author: rguenth
Date: Mon Jun 15 10:05:29 2009
New Revision: 148486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148486
Log:
2009-06-15 Richard Guenther
PR middle-end/40439
--- Comment #12 from irar at il dot ibm dot com 2009-06-15 09:58 ---
(In reply to comment #9)
> The patch in comment #8 fixes the failures reported in comment #7. I now see
> (powerpc-apple-darwin9 with -m64):
> FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
>
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-15 09:55
---
extern "C" int printf(const char*, ...);
struct A
{
A() : value(1) { printf("A::A %d\n", value); }
int value;
};
template
struct B
{
static A a;
};
template A B::a = A();
template
struc
--- Comment #10 from dominiq at lps dot ens dot fr 2009-06-15 09:42 ---
> This Darwin problem is clearly not the same bug as 40385, so it needs a new
> Bugzilla entry.
This is now pr40444.
> I expect that a patch to xfail err_bad_abi.c on *-*-* would be approved.
Probably err_bad_type
See comment #4 of pr40385:
=== libffi Summary for unix ===
# of expected passes1594
# of expected failures 10
# of unsupported tests 15
Running target unix/-m64
FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test
...
FAIL: libffi.special/unwi
--- Comment #9 from aph at gcc dot gnu dot org 2009-06-15 09:29 ---
I need to know why it's crashing. Usually there's some sort of error message.
If there's not, there's no choice but to debug.
This Darwin problem is clearly not the same bug as 40385, so it needs a new
Bugzilla entry.
--- Comment #8 from dominiq at lps dot ens dot fr 2009-06-15 09:24 ---
> That was answered on Fri, 12 Jun by Kaz Kojima.
Not exactly, it answered about some future goal of the tests, but without any
name of platform(s) on which they work. My implicit question is "does it make
any sense
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-15 09:19
---
(In reply to comment #0)
> I can't use "template<> A B::a = something;" form (which would help)
> because I have only empty ctor (like in the case of map).
I'm not sure what you mean but this works fine:
templat
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-15 09:19 ---
> That probably is my fault. However, I can't do anything about it until I see
> the testsuite log file.
The log file looks like:
...
Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/
/op
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-15 09:09 ---
Created an attachment (id=18002)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18002&action=view)
Fix
OK, the statement is fine except that it is not gimple ;-). Fixed
with this patch, I will submit it if
--- Comment #6 from aph at gcc dot gnu dot org 2009-06-15 09:08 ---
Re http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00929.html:
That was answered on Fri, 12 Jun by Kaz Kojima.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
--- Comment #5 from aph at gcc dot gnu dot org 2009-06-15 09:07 ---
That probably is my fault. However, I can't do anything about it until I see
the testsuite log file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-15 09:07 ---
Created an attachment (id=18001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18001&action=view)
Fix
This was quite a serious oversight on my part, I wonder how it went
for so long unnoticed. I am about to b
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-15 09:05 ---
I have applied the following patch on revision 148472
diff -up libffi/testsuite/libffi.call/err_bad_abi.c
/opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_abi.c
--- libffi/testsuite/libffi.call/err_bad_abi.
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 08:52 ---
(In reply to comment #2)
> COmplete code for the test case including the module iso_varying_string
Works with: gfortran 4.3.3, ifort 11, sunf95, NAG f95 5.1 (w/o flush
statements)
Fails (abort) with gfortran 4.4.1/4.
--- Comment #2 from jpr at csc dot fi 2009-06-15 08:28 ---
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.
>
> * * *
>
> gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> print the following:
>
> E
> S, S
> E
> E, E !
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 07:46 ---
Paul, I CC you as you are our generic-resolution expert.
* * *
gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
print the following:
E
S, S
E
E, E ! << you expect an "S, S" here
Looki
99 matches
Mail list logo
