There seems to be a problem with mangling, STDCALL and BIND(C), see
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/eb7ca487876d9420
--
Summary: STDCALL mangling problem for strings @8 instead of @4
Product: gcc
Version: 4.5.0
St
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-07-29 04:40
---
Created an attachment (id=18265)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18265&action=view)
A simple patch to resolve the problem
This patch solves the original test case. It does require modificatio
--- Comment #1 from spop at gcc dot gnu dot org 2009-07-29 04:11 ---
Hi,
>From what I read this has nothing to do with Graphite. Could you
please reduce the bug using ideas from:
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
I am using to compile everything with a working comp
--- Comment #4 from mckelvey at maskull dot com 2009-07-29 01:47 ---
(In reply to comment #3)
> Created an attachment (id=18254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18254&action=view) [edit]
> patch to fix the failure
>
> This patch fixes the failure on x86_64 -> alpha c
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-29 01:29 ---
Introduced in revision 147980 (SRA).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rleigh at debian dot org 2009-07-28 23:15 ---
Ah, so it's a defect in the actual C++ standard rather than GCC?
I was somewhat confused because while this fails:
psess = this->chroot->get_facet();
splitting it into its component parts always succeeds:
sbuild:
--- Comment #6 from rleigh at debian dot org 2009-07-28 23:03 ---
Created an attachment (id=18264)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18264&action=view)
Preprocessed source for g++-4.5.0 (svn 149777)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-28 23:03 ---
If it is getting you an internal error, then it is usually it is because the
attachments are too big.
As for the other issue, there is a C++ defect report about this case, which
consider this as dependent but a memb
--- Comment #4 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18263&action=view)
Preprocessed source for g++-4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #3 from rleigh at debian dot org 2009-07-28 23:02 ---
Created an attachment (id=18262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18262&action=view)
Preprocessed source for g++-4.3.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #2 from rleigh at debian dot org 2009-07-28 23:00 ---
Yes, the class for the this pointer is a template:
template
class test_chroot_base : public TestFixture
Adding template as you suggest
psess = this->chroot->template get_facet();
does allow the source to compile.
I
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-28 22:51 ---
Does:
psess = this->chroot->template get_facet();
make it work? Is the class where you use this a template?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897
--- Comment #12 from htl10 at users dot sourceforge dot net 2009-07-28
22:49 ---
Still broken with 4.3.1, with alphaev68-dec-osf5.1a -
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02507.html
Am about to submit the testsuite result for 4.3.3 and 4.4.1, and I think the
result is simi
The following code fails to compile:
std::tr1::shared_ptr psess;
psess = this->chroot->get_facet();
However, this code compiles without error:
std::tr1::shared_ptr psess;
psess = chroot->get_facet();
The only difference is the deletion of the "this" pointer. chroot is a member
of the c
--- Comment #1 from lessen42+gcc at gmail dot com 2009-07-28 22:27 ---
More specifically, on x86_64 the following is generated with gcc-4.4 -O3
-march=core2 -S
_dct2x2dc_dconly:
movswl 2(%rdi),%edx
pushq %rbp
addw(%rdi), %dx
movswl 6(%rdi),%eax
--- Comment #3 from rmh at gcc dot gnu dot org 2009-07-28 22:11 ---
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-07-28 21:33 ---
I can confirm that if we schedule pass_ccp right after pass_sra_early,
g gets inlined. Moreover, if we schedule one more pass_forwprop right
afterwards, even the testcase for PR 3713, comment #12 gets optimized
as i
I currently am keeping the Haiku operating system up to date with GCC 4.4 and
trunk, with plans of eventually getting the code for our GCC port committed
into GCC's repository.
I was keeping up to date by doing builds periodically based on 4.4 snapshots,
and assumed all would be well when 4.4.1 ro
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-07-28 20:59 ---
Ha, please disregard the previous message, obviously I had to make a
fool out of myself before realizing that loops in the inlining plan
are the bug, not how we handle them.
The reason there are such loops is that i
--- Comment #10 from htl10 at users dot sourceforge dot net 2009-07-28
20:42 ---
The 'find bad option' problem was already reported for solaris as bug 38715 .
just FYI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-28 20:36
---
Already fixed in 4.4.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from htl10 at users dot sourceforge dot net 2009-07-28
20:30 ---
Sorry for the noise - the 'find: bad option -path' error message of mine is
genuine - gcc 4.4 (classpath) requires GNU findutils syntax which doesn't work
with DEC/Tru64 find. Am filing a separate bug now.
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-28 20:14 ---
When I move "e->inline_failed = CIF_OK" in cgraph_mark_inline_edge()
until after call to cgraph_clone_inlined_nodes(), the endless
recursion goes away. However, I now get an assert in
cgraph_estimate_size_after_inli
With G++ 4.3.3 and 4.4.0 from Ubuntu Jaunty, I get:
ice.cpp: In instantiation of âs<0>â:
ice.cpp:19: instantiated from here
ice.cpp:14: internal compiler error: in tsubst, at cp/pt.c:9687
from this test program:
int foo(int x, ...);
template
int bar()
{
return 0;
}
template
struct
--- Comment #3 from ubizjak at gmail dot com 2009-07-28 20:01 ---
What about using ^ and $ throughout the testsuite instead of inventing regular
expressions involving \n and \r in all possible combinations (i.e. (\n|\r\n|\r)
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-28 19:38
---
One step at a time, Dave ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #4 from hjl dot tools at gmail dot com 2009-07-28 18:58 ---
It still fails on Linux/ia64.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from dave at boost-consulting dot com 2009-07-28 18:42
---
The next step would be to verify that the penalty is eliminated when using
boost::function / tr1::function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
make bootstrap4-lean failed with 4.4.0 and 4.4.1 with crtfastmath.o comparison.
The last gcc version I can make bootstrap4-lean was 4.3.3 (and before that,
4.3.1) which was what I tried building 4.4.x with.
Strangely "make" (which I understand do a 3 stage boostrap) doesn't have this
problem, but
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-07-28 18:28
---
Doesn't reproduce, please close as invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40890
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-28 18:12 ---
Shouldn't test_summary remove "^M?" when sending out emails?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-28 18:09 ---
> Could somone check if this pr has not been fixed (hidden) by some recent
> changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work
> on i686-apple-darwin9 at this revision) on i686-apple-darwi
--- Comment #8 from htl10 at users dot sourceforge dot net 2009-07-28
18:06 ---
I have a slightly different message on alphaev68-dec-osf5.1a with gcc 4.4.1,
but possibly the same problem: (I can bootstrap 4.3.3, but no luck with
4.4.0/4.4.1):
find ../../../../.
--- Comment #7 from htl10 at users dot sourceforge dot net 2009-07-28
17:53 ---
I probably have a similiar bug about length of commend line with 4.4.1 which I
shall file now.
--
htl10 at users dot sourceforge dot net changed:
What|Removed |Added
-
--- Comment #2 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40829
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150169
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-0
--- Comment #5 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40848
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150169
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-0
--- Comment #7 from hjl at gcc dot gnu dot org 2009-07-28 16:51 ---
Subject: Bug 40822
Author: hjl
Date: Tue Jul 28 16:51:19 2009
New Revision: 150169
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150169
Log:
2009-07-28 H.J. Lu
Backport from mainline:
2009-0
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-07-28 16:38 ---
Subject: Bug 40759
Author: hubicka
Date: Tue Jul 28 16:37:50 2009
New Revision: 150168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150168
Log:
PR tree-optimization/40759
* tree-ssa-dce.c
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:34 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:33 ---
Subject: Bug 40878
Author: jakub
Date: Tue Jul 28 16:33:08 2009
New Revision: 150167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150167
Log:
PR fortran/40878
* openmp.c (gfc_match_omp_clause
Consider the following C code:
#include
void dct2x2dc_dconly( int16_t d[2][2] )
{
int d0 = d[0][0] + d[0][1];
int d1 = d[1][0] + d[1][1];
d[0][0] = d0 + d1;
d[0][1] = d0 - d1;
}
The following is generated with arm-none-linux-gnueabi-gcc-4.4.0 -O3
-mcpu=cortex-a8 -S
dct2x2dc_dcon
--- Comment #3 from jakub at gcc dot gnu dot org 2009-07-28 16:21 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from dominiq at lps dot ens dot fr 2009-07-28 16:21 ---
Could somone check if this pr has not been fixed (hidden) by some recent
changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work
on i686-apple-darwin9 at this revision) on i686-apple-darwin9 at
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:16 ---
Subject: Bug 40878
Author: jakub
Date: Tue Jul 28 16:15:47 2009
New Revision: 150165
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150165
Log:
PR fortran/40878
* openmp.c (gfc_match_omp_clause
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-28 16:11 ---
Subject: Bug 40891
Author: jakub
Date: Tue Jul 28 16:11:21 2009
New Revision: 150164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150164
Log:
PR testsuite/40891
* gcc.dg/cdce1.c: Adjust note
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 16:10 ---
Subject: Bug 40891
Author: jakub
Date: Tue Jul 28 16:09:58 2009
New Revision: 150163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150163
Log:
PR testsuite/40891
* gcc.dg/cdce1.c: Adjust note
cp/error.c:maybe_warn_cpp0x takes a string that is an English language
fragment and inserts it into a sentence for a diagnostic; the string in
question is neither translated nor extracted for gcc.pot. Whole sentences
should be used for diagnostics; either pass an enum to this function
rather than
--- Comment #2 from gnu_andrew at member dot fsf dot org 2009-07-28 15:09
---
Fixed with above commit.
--
gnu_andrew at member dot fsf dot org changed:
What|Removed |Added
---
--- Comment #1 from gandalf at gcc dot gnu dot org 2009-07-28 15:08 ---
Subject: Bug 40616
Author: gandalf
Date: Tue Jul 28 15:08:12 2009
New Revision: 150161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150161
Log:
Fix for PR40616: missing java.io.PrintStream constructors.
2
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-28 14:43 ---
(In reply to comment #1)
> I certainly can't reproduce any kind of segfault with this.
Neither can I. Regarding both examples (comment 0 and comment 1), ifort 11.1
happily accepts both.
I am not sure whether it is
--- Comment #3 from jv244 at cam dot ac dot uk 2009-07-28 14:34 ---
(In reply to comment #1)
> I certainly can't reproduce any kind of segfault with this.
It could be that it segfaults for Bill because 'ftn' adds -static to the
compiler options, but doesn't link libpthread with '-Wl,--w
--- Comment #5 from mans at mansr dot com 2009-07-28 14:24 ---
Just to be clear, this bug report is about *all* calls through function
pointers. PR19599 only mentions a failed tail-call optimisation. That the
example in this bug would benefit from this optimisation is secondary.
I agr
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-07-28 14:04
---
You didn't say how you configured the build, but you might want to use
something like:
--with-host-libstdcxx='/usr/local/gcc-4.4/lib/libstdc++.a -lm'
as documented at http://gcc.gnu.org/install/configure.html
Revision 150143:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg01026.html
caused:
FAIL: gcc.dg/cdce1.c scan-tree-dump cdce "cdce1.c:16: note: function call is
shrink-wrapped into error conditions."
FAIL: gcc.dg/cdce2.c scan-tree-dump cdce "cdce2.c:16: note: function call is
shrink-wrapped into error
--- Comment #2 from longb at cray dot com 2009-07-28 13:47 ---
The text at [75:19-20] of the OpenMP 2.5 standard, May 2008, says:
"Variables that appear in namelist statements, in variable format expressions,
and in Fortran expressions for statement function definitions, may not appear
/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/xgcc
-B/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/./prev-gcc/
-B/mingw/gcc/gcc-4.5.0/i686-pc-mingw32/mingw/i686-pc-mingw32/bin/
-L/home/rainer/software/build/i686-pc-mingw32/gcc-4.5.0/gcc/i686-pc-mingw32/winsup/ming
--- Comment #4 from janus at gcc dot gnu dot org 2009-07-28 13:31 ---
Fixed with r150134. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-28 13:28 ---
Honza, unless there are any new problems, can you commit the patch? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-28 13:12 ---
We have the following cgraph nodes related to daxpy:
daxpy/17(-1) @0x75fc8700
called by: dgesl/3 (1.00 per call) dgesl/3 (1.00 per call)
calls:
dgefa/7(7) @0x75f7b100 174 time, 45 benefit 138 size, 36 be
--- Comment #3 from dodji at gcc dot gnu dot org 2009-07-28 12:39 ---
Subject: Re: New: namespaces represented incorrectly in
debug_pubnames
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01579.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-28 12:20 ---
I certainly can't reproduce any kind of segfault with this.
And, it is unclear to me whether this restriction (why it is there at all,
doesn't make much sense) is meant just for statement functions referenced
within th
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-28 12:14 ---
Fixed with r150154. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-28 12:09 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The point made is correct but there is something you've missed in your
> > patch !
> > loading lr with the address of the function you want to call, destroys th
--- Comment #17 from joseph at codesourcery dot com 2009-07-28 11:55
---
Subject: Re: String not extracted for translation
On Mon, 27 Jul 2009, manu at gcc dot gnu dot org wrote:
> --- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 ---
> (In reply to comment #2
When trying to use gcj -C instead of a symlink to ecj as gcj's javac (with
options appropriately changed with a script), I ran across an interesting issue
building OpenJDK:
gcj -C -g -d lib/hotspot-tools -fsource=1.5
-I'hotspot-tools:/home/andrew/projects/openjdk/icedtea/netx:/mnt/build
--- Comment #2 from janus at gcc dot gnu dot org 2009-07-28 11:40 ---
Subject: Bug 40882
Author: janus
Date: Tue Jul 28 11:40:42 2009
New Revision: 150154
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150154
Log:
2009-07-28 Janus Weil
PR fortran/40882
* tran
--- Comment #2 from per at bitempire dot com 2009-07-28 11:23 ---
Sorry, you're right - it works fine with gcc 4.3 and later. I must have
accidentally linked to libgomp 4.2 which is a part of llvm-gcc.
I apologize for the inconvenience.
--
per at bitempire dot com changed:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-28 11:22 ---
After early SRA we get
f$x_8 = g;
D.2142_6 = f$x_8;
D.2141_7 = D.2142_6 (3);
which now misses a constant propagation of &g into the call which is why
inlining doesn't catch this opportunity. Put one in and t
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-28 11:09 ---
The tree optimizers canonicalize the loop to
:
# i_5 = PHI
# ivtmp.23_1 = PHI
f2 ();
i_3 = i_5 + 1;
ivtmp.23_4 = ivtmp.23_1 - 1;
if (ivtmp.23_4 != 0)
goto ;
else
goto ;
:
goto ;
But then
--- Comment #14 from burnus at gcc dot gnu dot org 2009-07-28 09:57 ---
(In reply to comment #13)
> Still missing in intrinsics (at least as far as
For those which have one-dimensional arrays, one should consider adding the
checks in trans*.c as this is faster for the non -fcheck=bounds
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-07-28 09:04
---
Still missing in intrinsics (at least as far as
grep -L bounds `grep -l gfc_array *.c` tells me):
associated.c
date_and_time.c
dtime.c
etime.c
iso_c_binding.c
move_alloc.c
random.c
stat.c
unpack_generic.c
Missing
--- Comment #3 from lessen42+gcc at gmail dot com 2009-07-28 08:45 ---
(In reply to comment #2)
> The point made is correct but there is something you've missed in your patch !
> loading lr with the address of the function you want to call, destroys the
> return address ,- so your code i
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-28 08:33 ---
In a similar vain: One could introduct an option to disable warning for the
deleted features (such as using real-valued loops) - currently, those warnings
alre always printed, hiding other warnings in all the output.
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-28 08:29 ---
(In reply to comment #0)
> Consider the following code:
>
> int (*indirect_func)();
>
> int indirect_call()
> {
> return indirect_func();
> }
>
> gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
>
--- Comment #41 from irar at il dot ibm dot com 2009-07-28 08:12 ---
That requires pattern recognition. MIN/MAX_EXPR are recognized by the first
phiopt pass, so MIN/MAXLOC should be either also recognized there or in the
vectorizer. (The phiopt pass transforms if clause to MIN/MAX_EXPR.
--- Comment #2 from aph at gcc dot gnu dot org 2009-07-28 08:02 ---
This is actually a regression in debuginfo: the line number info is being
corrupted, somewhere after the front end. I don't know if this was caused by
the gimplify unit-at-a-time patch.
--
aph at gcc dot gnu dot org
--- Comment #42 from jv244 at cam dot ac dot uk 2009-07-28 07:37 ---
another issue I found is this:
> gfortran -fwhole-file test.f90
/tmp/cciOiaMB.o: In function `__m_MOD_b':
test.f90:(.text+0xa): undefined reference to `c_'
collect2: ld returned 1 exit status
> cat test.f90
SUBROUTIN
--- Comment #5 from bmerry at gmail dot com 2009-07-28 07:28 ---
Thanks, I wasn't aware of that. It's slightly annoying that the behaviour is
different from glibc (I use -std=c89 so that the compiler keeps me honest,
since I'm working on code that has to compile on compilers that still h
78 matches
Mail list logo
