--- Comment #3 from ubizjak at gmail dot com 2009-07-24 06:25 ---
Please also add the testcase from Comment #1 to gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-24 06:27 ---
A hint, please, about why the patch of comment #2 would be the correct fix. As
far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
up other passes' mess. This patch also introduces a pass
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-24 06:59 ---
Because HAVE_cc0 is only for cc0 targets, and ARM is not one of those?
You should stop jumping to peepholes for every missed optimization you find.
There is a csecc pass (part of cse2) that should handle this. You
--- Comment #4 from carrot at google dot com 2009-07-24 07:37 ---
Just as I've figured out HAVE_cc0 is disabled. And cse_condition_code_reg does
nothing for thumb target.
I also found that the conditional branch instructions is always in the same
insn pattern as the previous compare
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-24 07:57 ---
Subject: Bug 40643
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
PR fortran/31067
*
--- Comment #29 from jakub at gcc dot gnu dot org 2009-07-24 07:57 ---
Subject: Bug 31067
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
PR fortran/31067
*
--- Comment #30 from burnus at gcc dot gnu dot org 2009-07-24 08:19 ---
Regarding the just committed inline version: It would be interesting to know
whether it is vectorizable (with/without -ffinite-math-only [i.e.
-ffast-math]).
Additionally, for size-1 result arrays, the function
--- Comment #29 from burnus at gcc dot gnu dot org 2009-07-24 08:21 ---
Probably fixed by the commit of PR 40643 comment 7
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150041
Log:
PR fortran/40643
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-24 08:25 ---
The fact that the move sets the condition code is not modelled in the insn.
From .expand dump:
(insn 6 5 7 3 t.c:5 (set (reg/v:SI 133 [ v ])
(reg:SI 0 r0)) -1 (nil))
From -dAP output:
@(insn 6 5 7 t.c:5
--- Comment #31 from jakub at gcc dot gnu dot org 2009-07-24 08:30 ---
Vectorization questions I'll defer to Ira.
For !optimize I even had a change to forcibly use the function call instead of
inline version. But it didn't really work, as there are only array versions of
the library
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 08:48 ---
In fact even the compare isn't a separate insn:
@(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133])
@(reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil))
@ 0x0004
mov r1, r0 @ 6
--- Comment #10 from rguenther at suse dot de 2009-07-24 09:02 ---
Subject: Re: [4.5 Regression] Revision 149750 failed
483.xalancbmk in SPEC CPU 2006
On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
--- Comment #9 from hjl dot tools at gmail dot com 2009-07-23 19:16
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-24 09:07
---
Implemented here:
2008-05-23 Kaveh R. Ghazi gh...@caip.rutgers.edu
* builtin-types.def (BT_FN_INT_INT_INT_INT_INT_INT_VAR): New.
* builtins.c (fold_builtin_fpclassify): New.
--- Comment #27 from jakub at gcc dot gnu dot org 2009-07-24 09:46 ---
These are small helper programs. The real question is if -Wl,--relax is used
on the gcc line that actually fails with the linker errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-07-24 10:12
---
(In reply to comment #3)
Simple case :
templatetypename C struct A {};
templatetypename C struct B { struct Inner {}; };
templatetypename K
struct Atypename BK::Inner {};
4.1.2/VS2005 compile
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-24 10:12 ---
Subject: Bug 40807
Author: davek
Date: Fri Jul 24 10:12:16 2009
New Revision: 150042
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150042
Log:
PR libffi/40807
* src/x86/ffi.c
--- Comment #7 from davek at gcc dot gnu dot org 2009-07-24 10:22 ---
Fixed at r.150042.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-07-24 10:24
---
With the newest whole-file patch I instead get
#1 0x087a1c89 in tree_check_failed (node=0xb6e9fcb0,
file=0x8b9d398 /home/richard/src/trunk/gcc/fortran/trans-types.c,
line=2010, function=0x8b9da9d
--- Comment #37 from rguenth at gcc dot gnu dot org 2009-07-24 10:27
---
We then get to the next ICE ...
(gdb) up
#1 0x0819bfaa in gfc_create_module_variable (sym=0x22cb3750)
at /home/richard/src/trunk/gcc/fortran/trans-decl.c:3327
3327 gcc_assert (TYPE_CONTEXT (decl) ==
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-07-24 10:29
---
(In reply to comment #4)
I think this is invalid because K is used in a non-deduced context
Which is the same problem as with the original testcase - this is not a bug in
gcc.
According to 14.5.4.1
--- Comment #6 from paolo dot carlini at oracle dot com 2009-07-24 10:42
---
Closing...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-07-24 10:56
---
Too large, not reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #5 from janus at gcc dot gnu dot org 2009-07-24 11:00 ---
Subject: Bug 40822
Author: janus
Date: Fri Jul 24 11:00:01 2009
New Revision: 150047
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150047
Log:
2009-07-24 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #39 from jv244 at cam dot ac dot uk 2009-07-24 11:29 ---
(In reply to comment #36)
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-24 11:56
---
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their
According to documentation (quote):
-
-malign-double
-mno-align-double
Control whether GCC aligns double, long double, and long long variables on
a two word boundary or a one word boundary. Aligning double variables on a two
word boundary will produce code that runs somewhat faster on a
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-24 12:05
---
The resolution of the DR is implemented in mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-24 12:05
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2009-07-24 12:14 ---
Fixed with r150047. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-24 12:16
---
GCC does not assume the stack is aligned to 16 bytes if it cannot prove that it
is. That GCC aligns the stack to 16 bytes itself is compliant with the
requirement of 4 byte stack alignment.
So I completely miss
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-24 12:21 ---
It works on SLES11 as well.
rguent...@scandium:/tmp g++ -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-24 12:26 ---
indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from jv244 at cam dot ac dot uk 2009-07-24 12:27 ---
(In reply to comment #20)
As noticed in PR40011,
All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function
--- Comment #1 from bugtrack at roumenpetrov dot info 2009-07-24 12:40
---
P.S.: issue is tested on 32-bit x86 platform
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845
--- Comment #28 from giffordj at la dot twcbc dot com 2009-07-24 13:12
---
Looks like it.
gcc -isystem /usr/include -m32 -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat
I downloaded
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz and
attempted to compile the file listed below. I got the message:
a.f90: In function speak:
a.f90:7:0: internal compiler error: tree check: expected function_decl, have
namespace_decl in gfc_finish_var_decl,
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-07-24 14:08
---
(In reply to comment #6)
In fact even the compare isn't a separate insn:
There's a reason for that.
If you separate compares from uses of the flags then reload may end up
inserting add or mov instructions in
--- Comment #11 from hjl dot tools at gmail dot com 2009-07-24 14:16
---
(In reply to comment #10)
Subject: Re: [4.5 Regression] Revision 149750 failed
483.xalancbmk in SPEC CPU 2006
On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
--- Comment #9 from hjl dot
--- Comment #8 from doko at ubuntu dot com 2009-07-24 14:37 ---
same behaviour with the 4.4.1 release
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-24 15:30 ---
That has the whole-file patch applied appearantly.
582 /* Code with static variables must not be inlined. */
583 if (TREE_STATIC (decl) DECL_CONTEXT (decl))
584 DECL_UNINLINABLE(DECL_CONTEXT
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-07-24 15:32
---
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before cgraph_finalize_compilation_unit?
Thanks.
--
--- Comment #24 from jakub at gcc dot gnu dot org 2009-07-24 15:37 ---
I have a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from nvachhar at google dot com 2009-07-24 15:39 ---
Subject: Re: ICE in iv_analyze_def caused by
stale REG_UNUSED note
loop-iv does need notes, albeit indirectly through the single_set
function. single_set looks at the REG_UNUSED note, and if all but one
set
--- Comment #23 from jv244 at cam dot ac dot uk 2009-07-24 15:43 ---
(In reply to comment #22)
Can you run it in a debugging session and do
(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit
and see if ggc_collect is reached before
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-24 15:44 ---
long double is 12 bytes, C requires arrays to pack dense, thus a 12 byte
long double has to be aligned to 4 bytes at least in arrays.
GCC 3.3 to 4.5 do
sizeof/offset: o_d=12/08 o_ld=16/04 o_l=08/04 o_ll=12/08
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-24 15:46
---
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #8 from zlynx at acm dot org 2009-07-24 15:47 ---
I will work on trying it with libunwind and then with binutils 2.19. Those seem
to be the differences so far.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-07-24 15:54
---
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
Index: gcc/fortran/trans-types.c
--- Comment #26 from jv244 at cam dot ac dot uk 2009-07-24 16:04 ---
(In reply to comment #24)
Ok, that confirms this bug is unrelated to the GC issue in the other PR.
Well, there are two bugs. The first one is gone with your
'cgraph_finalize_function (ftn_main, true)' change
--
--- Comment #27 from jv244 at cam dot ac dot uk 2009-07-24 16:05 ---
(In reply to comment #25)
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).
Can you try
this fixes the segfault, but I now
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-07-24 16:12
---
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #29 from jv244 at cam dot ac dot uk 2009-07-24 16:48 ---
(In reply to comment #28)
Add
TYPE_CANONICAL (fat_type) = base_type;
after the build_distinct_type_copy call.
Yep... goes fine now
arghh... further testing on standard sources (-g?) reveals:
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-07-24 16:51
---
Hmm, that looks unrelated ...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #31 from jv244 at cam dot ac dot uk 2009-07-24 16:56 ---
(In reply to comment #30)
Hmm, that looks unrelated ...?
doesn't seem to happen on a clean trunk ( a few days more recent ). This is a
reduced testcase for this failure:
gfortran -g bug.f90
bug.f90: In function
--- Comment #32 from jv244 at cam dot ac dot uk 2009-07-24 17:00 ---
(In reply to comment #31)
doesn't seem to happen on a clean trunk ( a few days more recent )
it is definitely caused by the current patch (i.e. reverting it fixes the
issue):
Index: trans-types.c
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 17:04 ---
Then we should write a new function, something like this in df.h perhaps:
/* Given an INSN, return a SET expression if the insn has only one
SET whose SET_DEST is used. If SET_DEST is memory, then the SET is
--- Comment #25 from whaley at cs dot utsa dot edu 2009-07-24 17:05 ---
Richard,
GCC does not assume the stack is aligned to 16 bytes if it cannot prove that
it is.
If this is true now, it is a change from previous behavior. When I reported
this problem, gcc *assumed* 16-byte
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-07-24 17:14
---
Yeah, it's caused by the change. We don't generate a real proper copy (we
don't copy the fields so their context is wrong). Previously only a single
debug-info copy was emitted via using TYPE_MAIN_VARIANT.
We
--- Comment #34 from jv244 at cam dot ac dot uk 2009-07-24 17:31 ---
(In reply to comment #33)
We can work around this by also doing
TYPE_MAIN_VARIANT (fat_type) = base_type;
though that's a bit hairy ... (does it still solve your oroginal problem
then?)
yes, the original
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Known to
MODULE TT
INTERFACE M
MODULE PROCEDURE M1,M2
END INTERFACE
CONTAINS
SUBROUTINE M1(I,*)
INTEGER :: I
RETURN 1
END SUBROUTINE
SUBROUTINE M2(I,J)
INTEGER :: I,J
END SUBROUTINE
END MODULE
USE TT
CALL M(1,*2)
write(6,*) Hi
2 CONTINUE
END
--
Summary: [4.5 Regression] ICE
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to work||4.4.1
Target Milestone|--- |4.5.0
this should be an OK program, but gives a strange warning, and segfaults at run
time. 4.1.2 works fine.
program test_elemental
print *,'Transfer size:',transfer_size((/0.,0./),(/'a','b'/))
contains
elemental function transfer_size (source, mold)
real, intent(in) :: source
--- Comment #7 from nvachhar at google dot com 2009-07-24 17:47 ---
Subject: Re: ICE in iv_analyze_def caused by
stale REG_UNUSED note
This looks reasonable to me. Given the caveats you mention in the
comment, this would need to be tested for correctness (esp. w.r.t. the
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-24 18:41 ---
Confirmed. Janus - I think it could be do to your 4.5 argument checking
patches.
==8885== Invalid read of size 8
==8885==at 0x4C2050: compare_type_rank (interface.c:474)
==8885==by 0x4C20C4:
On lin 5257 of gcc/fortran/module.c there is this code:
gfc_fatal_error (Wrong module version '%s' (expected '
MOD_VERSION ') for file '%s' opened
at %C, atom_string, filename);
Format strings for gfc_fatal_error are
--- Comment #35 from rguenth at gcc dot gnu dot org 2009-07-24 19:14
---
Ok, less hacky is the following.
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c.orig 2009-07-24 21:13:28.0 +0200
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-24 19:34
---
Hm, I'm quite lost here. But at least here is a simplified testcase which
shows the same differences.
class XalanDOMString { };
class XObject {
public:
virtual const XalanDOMString str() const;
};
class
at gmail dot com
GCC build triplet: gcc version 4.5.0 20090724
GCC host triplet: Linux 2.6.27-gentoo-r8 x86_64 AMD
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850
Hello,
I think that I detected a bug in the gcc mmix port.
If the example program 'jmpbug.c' (please see attachment) is compiled
with default options, it works; if it is compiled with '-O2' or '-O3'
option, it does not work (because jmp_buf is damaged):
C:\temp\bugmmix-gcc -save-temps jmpbug.c
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-07-24 19:52
---
I see what goes wrong. preparing a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-07-24 19:59
---
Index: cp/cp-gimplify.c
===
--- cp/cp-gimplify.c(revision 150041)
+++ cp/cp-gimplify.c(working copy)
@@ -804,10 +804,14 @@ cp_genericize_r
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-07-24 20:01
---
The short explanation is that we did not properly walk DECL_INITIAL of the
vars in the BIND_EXPR. Not with walking BIND_EXPR_VARS either because we
stop at VAR_DECLs in cp_genericize_r before walking its
gfortran seems to deallocate a pointer which was not allocated or need not be
allocated. The program below compiles, but when executed returns the following
error message:
a.out(8814) malloc: *** error for object 0x1fa2: Non-aligned pointer being
freed
*** set a breakpoint in malloc_error_break to
--- Comment #1 from juergen dot reuter at desy dot de 2009-07-24 20:04
---
Created an attachment (id=18249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18249action=view)
main program for pointer output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851
--- Comment #16 from hjl dot tools at gmail dot com 2009-07-24 20:06
---
(In reply to comment #14)
Index: cp/cp-gimplify.c
===
--- cp/cp-gimplify.c(revision 150041)
+++ cp/cp-gimplify.c(working copy)
@@
Parallel sorts get ~10 times slower as one increases the vector size from
4*10^9 to 5*10^9, perhaps at exactly 2^32, but this wasn't checked. The
example below is for a vector of ints but the same phenomenon is observed on a
vector of long longs.
To reproduce (sort_test.cc is below):
0. Adjust
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-24 20:29 ---
I suppose you are running into cache effects. Why do you think this is a GCC
bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
--- Comment #2 from jaffe at broadinstitute dot org 2009-07-24 20:43
---
Subject: Re: parallel sort run time increases ~10 fold
when vector size gets over ~4*10^9
If instead of sorting a vecint, one sorts a veclong long, there is still a
ten-fold
slowdown, as one increases the
--- Comment #1 from david dot sagan at gmail dot com 2009-07-24 21:05
---
Created an attachment (id=18250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18250action=view)
test.s file generated by the compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853
In brief: A namelist read of a structure component that is a vector when that
structure has another component that is a structure results in a runtime error.
Test file:
program test
implicit none
type tao_title_struct
character(2) justify
end type
type tao_plot_page_struct
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-24 21:15
---
Out of curiosity, did you try parallel-mode on that machine? Basically, just
add -D_GLIBCXX_PARALLEL, but refer to the documentation of course:
--- Comment #4 from jaffe at broadinstitute dot org 2009-07-24 21:20
---
Subject: Re: parallel sort run time increases ~10 fold
when vector size gets over ~4*10^9
Oh crap, yes I did, and now I see that I accidentally left off the first three
lines of sort_test.cc.
They are:
#define
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-24 21:23
---
So this is issue is just that you are not completely happy with the behavior of
parallel-mode. Ok... Let's see what Johannes thinks.
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #17 from hjl dot tools at gmail dot com 2009-07-24 21:55
---
Created an attachment (id=18251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18251action=view)
A testcase
[...@gnu-34 bad]$ make
/export/gnu/import/rrs/149748-fixed/usr/bin/g++ -S pr40834.C -o bad.s
--- Comment #1 from ludo at gnu dot org 2009-07-24 23:17 ---
(In reply to comment #0)
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
This differs from what I've seen in Debian build logs, where `jvgenmain' is
compiled at a later stage with `prev-gcc/xgcc'. Both
--- Comment #25 from jakub at gcc dot gnu dot org 2009-07-24 23:30 ---
Subject: Bug 34999
Author: jakub
Date: Fri Jul 24 23:30:39 2009
New Revision: 150069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150069
Log:
PR rtl-optimization/34999
* dwarf2out.c (struct
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-24 23:40 ---
(In reply to comment #1)
Dan Berlin, Diego, and I bounced this around on IRC a little. A couple of
things that came up:
- Diego suggested putting locuses on unshared INTEGER_CSTs as another
possible approach.
The application of:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01459.html
causes a build failure:
In file included from
/home/andrew/projects/classpath/gcj/sources/gcc/gcc/java/jcf-io.c:39:0:
/home/andrew/projects/classpath/gcj/sources/gcc/gcc/../zlib/zlib.h:1285:23:
error: conflicting types
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-25 02:08 ---
Also seen on i686-apple-darwin9.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
When I try to take the typeid of an __int128_t or a __uint128_t, I get an
undefined reference at link time, e.g., with gcc/4.4.1:
salm...@drdblogin6.en.desres$ cat typeid.cpp
#include typeinfo
const std::type_info ti(typeid(int)); // no problem
const std::type_info ti128(typeid(__int128_t));
91 matches
Mail list logo
