--- Comment #26 from spop at gcc dot gnu dot org 2009-08-15 06:47 ---
Subject: Bug 40981
Author: spop
Date: Sat Aug 15 06:46:59 2009
New Revision: 150787
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150787
Log:
Correct the use of ppl_Pointset_Powerset_C_Polyhedron_maximize.
2
--- Comment #25 from zaffanella at cs dot unipr dot it 2009-08-15 05:48
---
Subject: Re: [PPL-devel] aermod.f90 ICEs on -O2-fgraphite-identity
-floop-strip-mine
Sebastian Pop wrote:
>> Actually the error in gdb has changed with 1677_max.diff...
>>
>
> As expected: see the gc
I am going to take this on.
write( 10, ( "iarray =", *( i0, :, ","))) iarray
--
Summary: [F2008] Implement unlimited format item
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-08-15 02:17
---
Updating summary to reflect the focus of this PR.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-08-15 02:06
---
Toon, any word on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-08-15 02:03
---
I think we have moved past this and close it. 4.3 is regressions only.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from jvdelisle at gcc dot gnu dot org 2009-08-15 00:50
---
Fixed on 4.5.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-08-15
00:02 ---
With 1677_max applied to r150727 and with the patch...
--- ../../gcc-4.5-20090813/gcc/graphite-ppl.c.org 2009-08-14
19:37:03.0 -0400
+++ ../../gcc-4.5-20090813/gcc/graphite-ppl.c 2009-08-1
--- Comment #10 from zlynx at acm dot org 2009-08-15 00:02 ---
I erased every trace of experimental GCC versions and support libraries. Then I
rebuilt GCC 4.4.2 (from SVN) using the system provided GCC 4.3.
The problem went away.
It still worries me some because it seems to indicate th
--- Comment #8 from paolo dot carlini at oracle dot com 2009-08-14 23:43
---
In future work, remember to avoid comparing for strict equality floating point
numbers in the testsuite, isn't a well defined operation, as we all know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41061
--- Comment #7 from paolo dot carlini at oracle dot com 2009-08-14 23:34
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #6 from paolo at gcc dot gnu dot org 2009-08-14 23:33 ---
Subject: Bug 41061
Author: paolo
Date: Fri Aug 14 23:33:27 2009
New Revision: 150783
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150783
Log:
2009-08-14 Edward Smith-Rowland <3dw...@verizon.net>
--- Comment #26 from tobi at gcc dot gnu dot org 2009-08-14 22:58 ---
(In reply to comment #25)
> (In reply to comment #23)
>
> Actually, you're right. In nested loops, there's no way without copying.
>
If it weren't for the outermost loop it would actually be perfectly legal to
modif
--- Comment #23 from bagnara at cs dot unipr dot it 2009-08-14 22:49
---
What you can do is to use ppl_Linear_Expression_OK() and
ppl_Pointset_Powerset_C_Polyhedron_OK() to make sure you are not working with
corrupted objects.
If both the *_OK() functions evaluate to true, you could us
--- Comment #1 from siarhei dot siamashka at gmail dot com 2009-08-14
22:48 ---
Created an attachment (id=18370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18370&action=view)
xftrender.i
Preprocessed source. I did not manage to reduce it to a smaller testcase yet.
--
http
Terminal emulator from xfce4 segfaults if libXft-2.1.13 is compiled with
vanilla gcc 4.4.1 and '-fno-strict-aliasing -g -O2 -fno-omit-frame-pointer'
options.
Program received signal SIGSEGV, Segmentation fault.
0x408599cc in XftGlyphSpecRender (dpy=, op=,
src=, pub=0x1615f0, dst=31457359, srcx
--- Comment #25 from tobi at gcc dot gnu dot org 2009-08-14 22:46 ---
(In reply to comment #23)
Actually, you're right. In nested loops, there's no way without copying.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--- Comment #24 from tobi at gcc dot gnu dot org 2009-08-14 22:38 ---
(In reply to comment #23)
That's sad. I'm guessing that everytime it enters one of the inner loops, it
has to deal with the fact that the upper bound escaped. A way without all the
copying would be to set the DO var
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-14 22:11 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #5 from 3dw4rd at verizon dot net 2009-08-14 22:10 ---
(In reply to comment #4)
> Can you extract the tests that were failing and add them to the testsuite?
>
I will do that.
Also, I just found out something interesting as I was searching for a nice way
to test this. I fa
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-14 22:08 ---
Fixed with r150781. Thanks for reporting!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from tkoenig at gcc dot gnu dot org 2009-08-14 22:05
---
(In reply to comment #20)
> Created an attachment (id=18369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18369&action=view) [edit]
> updated patch
>
> Corrected patch, I copied the variables in the wrong o
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-14 22:03 ---
Subject: Bug 41070
Author: janus
Date: Fri Aug 14 22:02:45 2009
New Revision: 150781
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150781
Log:
2009-08-14 Janus Weil
PR fortran/41070
* reso
--- Comment #22 from tobi at gcc dot gnu dot org 2009-08-14 21:46 ---
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > From quickly looking at the code, the copy to real_to is probably
> > unnecessary
> > because loop bounds are passed through gfc_
--- Comment #21 from tobi at gcc dot gnu dot org 2009-08-14 21:44 ---
(In reply to comment #19)
> (In reply to comment #17)
> From quickly looking at the code, the copy to real_to is probably unnecessary
> because loop bounds are passed through gfc_evaluate_now before calling
> gfc_trans
--- Comment #20 from tobi at gcc dot gnu dot org 2009-08-14 21:31 ---
Created an attachment (id=18369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18369&action=view)
updated patch
Corrected patch, I copied the variables in the wrong order on loop entry,
clobbering the upper boun
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-14 21:29 ---
Smaller:
t1.f90
SUBROUTINE mltfftsg ( a, ldax, lday )
INTEGER, PARAMETER :: dbl = SELECTED_REAL_KIND ( 14, 200 )
INTEGER, INTENT ( IN ) :: ldax, lday
COMPLEX ( dbl ), INTENT ( INOUT ) :: a ( ldax, lday )
END S
--- Comment #1 from paolo dot carlini at oracle dot com 2009-08-14 21:26
---
As far as I know, this never ever worked correctly. I think there are some
basic static initialization order issues, Benjamin may know better..
--
paolo dot carlini at oracle dot com changed:
Wh
--- Comment #19 from mikael at gcc dot gnu dot org 2009-08-14 21:18 ---
(In reply to comment #17)
>From quickly looking at the code, the copy to real_to is probably unnecessary
because loop bounds are passed through gfc_evaluate_now before calling
gfc_trans_simple_do ( never mind if it g
--- Comment #36 from jvdelisle at gcc dot gnu dot org 2009-08-14 21:10
---
Subject: Bug 32784
Author: jvdelisle
Date: Fri Aug 14 21:10:06 2009
New Revision: 150779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150779
Log:
2009-08-14 Jerry DeLisle
PR libfortran/3278
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-14 21:03 ---
Ah, no. I know what happens.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-14 21:00 ---
Note that likely -fwhole-file is enough to trigger this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-14 20:26 ---
Regtest was successful. Will commit as obvious.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41070
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-08-14 20:18
---
Patch applied cleanly, building , and will test shortly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #17 from tobi at gcc dot gnu dot org 2009-08-14 19:55 ---
Created an attachment (id=18368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18368&action=view)
Speed up loops where the loop variable is used as function argument inside the
loop
This patch gives the good ass
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-14 19:54 ---
FIXED:
Author: ktietz
Date: Fri Aug 14 19:30:13 2009
New Revision: 150774
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150774
Log:
2009-08-15 Kai Tietz
* intrinsics/string_intrinsics_inc.c (stri
Initialization of an array mistakenly calls the copy constructor:
#include
std::iostream a[] = {std::iostream(0)};
int main()
{
}
Returns:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/ios_base.h:
In copy constructor 'std::basic_ios
>::basic_ios(const std::basic_i
--- Comment #4 from janis at gcc dot gnu dot org 2009-08-14 19:49 ---
Subject: Bug 41046
Author: janis
Date: Fri Aug 14 19:49:17 2009
New Revision: 150775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150775
Log:
PR c/41046
* decCommon.c ( decFloatShow): Define
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-14 19:46 ---
The same happens somewhere in SPEC2000 - I don't remember in which benchmark
exactly.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from tobi at gcc dot gnu dot org 2009-08-14 19:28 ---
Created an attachment (id=18367)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18367&action=view)
use const * when writing
Thomas, can you please test the attached patch with your testcase from comment
#6. I ca
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-14 19:26 ---
Simple patch (regtesting right now):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 150761)
+++ gcc/fortran/resolve.c (
--- Comment #2 from jv244 at cam dot ac dot uk 2009-08-14 19:13 ---
Created an attachment (id=18366)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18366&action=view)
reduced testcase
much smaller testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-14 19:10 ---
After all 4.4 is working, so it surely is a regression.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-14 19:10 ---
You are wrong to assume that the cast to char* changes the aliasing violation.
In fact it is an access via char which is able to be done to any other type.
So this:
(((unsigned short *)(char *)&(ans)))[1]
is an acce
--- Comment #146 from pinskia at gcc dot gnu dot org 2009-08-14 19:10
---
*** Bug 41072 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code:
#include
float floatsisf(int x) {
float ans = 0.5F;
long lexp = 24;
unsigned long frac = x;
unsigned long norm = 0x80;
unsigned long xint;
for (; frac < norm; frac <<= 1)
--lexp;
xint = (unsigned long)frac;
(((unsigned short *)(char *)&(ans)))[1]
/sw --with-mpc=/opt/mpc/build
Thread model: posix
gcc version 4.5.0 20090814 (experimental) [trunk revision 150730] (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-v' '-c' '-mtune=generic'
/Volumes/MacBook/opt/gcc/gcc4.5w/bin/../libexec/gcc/i686-apple-
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-08-14
18:19 ---
Also, as I mentioned off the mailing list to Dominique, fink cvs can be used to
build x86_64 packages for mpfr, gmp, ppl and cloog on Leopard which may save
folks some time trying to reproduce the problem
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-14 18:15 ---
Dominique,
are you sure that it works with 150730? Because this suspiciously looks like
fallout from my gfc_typespec patch, which is r150725.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41070
--- Comment #15 from tobi at gcc dot gnu dot org 2009-08-14 18:12 ---
I'm wondering if instead we can't simply mark all arguments to the transfer
functions in PRINT, WRITE and INTENT(IN) arguments as 'const *' instead of '*'.
Are there any reasons against this? I can't think of any exc
--- Comment #2 from tromey at gcc dot gnu dot org 2009-08-14 17:46 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #12 from jb at gcc dot gnu dot org 2009-08-14 17:45 ---
Subject: Bug 40863
Author: jb
Date: Fri Aug 14 17:44:50 2009
New Revision: 150765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150765
Log:
PR libfortran/40863 Fix r150107 moving new symbols to C99_1.1 node
Mo
--- Comment #1 from dominiq at lps dot ens dot fr 2009-08-14 17:33 ---
The code compiles on i686-apple-darwin9 at revision 150730, but gives the
reported error on powerpc-apple-darwin9 at revision 150736.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41070
--- Comment #21 from sebpop at gmail dot com 2009-08-14 17:16 ---
Subject: Re: aermod.f90 ICEs on -O2 -fgraphite-identity
-floop-strip-mine
> Actually the error in gdb has changed with 1677_max.diff...
>
As expected: see the gcc_assert in the patch
+/* Return in RES the maxi
The gimple.c patch in http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00770.html
causes gcc.c-torture/execute/stdarg-1.c to endlessly recurse in get_alias_set.
--
Summary: cycles with TYPE_CANONICAL and TYPE_MAIN_VARIANT
Product: gcc
Version: lto
Status:
When I attempt to compile the file listed below using the August 13 snapshot of
gfortran 4.5 on any platform I get the following message:
cd.f90:18.23:
CALL check_complements(the_beta%name)
1
Error: Components of structure constructor '' at (1) are PRIVATE
MODULE cdf_aux_
--- Comment #6 from ghazi at gcc dot gnu dot org 2009-08-14 16:44 ---
Subject: Bug 30789
Author: ghazi
Date: Fri Aug 14 16:44:36 2009
New Revision: 150760
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150760
Log:
PR middle-end/30789
* builtins.c (do_mpc_arg2):
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-14 16:30 ---
Created an attachment (id=18365)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18365&action=view)
testcase
'reduced' testcase, untar to get:
gfortran -flto -O2 -ffree-form -march=native -cpp -D__FFTSG mltfftsg_to
--- Comment #14 from jessieluv22 at gmail dot com 2009-08-14 16:27 ---
Created an attachment (id=18364)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18364&action=view)
Witha butterfil on a flower
It is a beautiful fly with colorful wings
--
http://gcc.gnu.org/bugzilla/sh
with current trunk compiling CP2K with -flto, I get the ICE below. As a side
note, lto needs already ~10Gb of RAM at this point. 'matmov' is a small
function:
SUBROUTINE matmov ( n, m, a, lda, b, ldb )
INTEGER :: n, m, lda
COMPLEX(8)
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-14 13:36 ---
Checking with eu-readelf -w info shows that -- according to "Line number
statements" -- the line jumping is really a GCC problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
--- Comment #8 from redi at gcc dot gnu dot org 2009-08-14 13:13 ---
Thanks, Richard.
If in-tree gmp is going to use --enable-cxx (which it seems to, even though I'm
not building with ppl and cloog-ppl) then should the c++ compiler be built in
stage1 automatically?
Alternatively, gmp's
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-14 13:02 ---
Use --enable-stage1-languages=c,c++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- Comment #6 from redi at gcc dot gnu dot org 2009-08-14 12:58 ---
I'm configuring with --enable-languages=c,c++ and still don't have a
prev-gcc/g++ (is g++ ever built in stage1?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- Comment #5 from rwild at gcc dot gnu dot org 2009-08-14 12:43 ---
Well in this case it has nothing to do with cpp, if you look at the respective
config.log file you see that earlier some in-tree g++ from an earlier stage,
/home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++
is
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-08-14 12:41 ---
This applies to both C and C++; the code in question is in libcpp.
Strictly, for C++ the compiler should act as if 'é' was replaced by
a UCN in phase 1 and so treat the second escape sequence like a valid
sequence \\u
--- Comment #17 from sezeroz at gmail dot com 2009-08-14 12:28 ---
Thank you all for your hard work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #2 from robert dot stewart at sig dot com 2009-08-14 12:23
---
I'll try to create a test case. As usual, it appears in complex library code
rather than in a simple context. Most (all?) of the cases in which I observed
it were in class or function templates, so it may be th
--- Comment #16 from bonzini at gnu dot org 2009-08-14 12:17 ---
committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from bonzini at gnu dot org 2009-08-14 12:14 ---
Subject: Bug 40934
Author: bonzini
Date: Fri Aug 14 12:14:04 2009
New Revision: 150754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150754
Log:
2009-08-14 Paolo Bonzini
PR target/40934
* confi
--- Comment #3 from dominiq at lps dot ens dot fr 2009-08-14 11:59 ---
> Interestingly, this benchmark is also the one that shows the best improvement
> from -floop-interchange...
I also see that ~20s versus ~34s, however comparing the outputs:
Maximum wand/quad abs rel mutual inducta
This is valid from 4.0 to 4.5. Very minor, agreed.
const char *cp = "\z\é\ ";
gives
foo.cc:1:1: warning: unknown escape sequence '\z'
foo.cc:1:1: warning: unknown escape sequence: '\303'
foo.cc:1:1: warning: unknown escape sequence: '\040'
I think the first one should also have its colon.
--
--- Comment #5 from hp at gcc dot gnu dot org 2009-08-14 11:39 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from hp at gcc dot gnu dot org 2009-08-14 11:37 ---
Subject: Bug 41064
Author: hp
Date: Fri Aug 14 11:36:45 2009
New Revision: 150751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150751
Log:
PR rtl-optimization/41064
* reload1.c (reload_as_needed
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-14 11:30 ---
I'm seeing this on RHEL5 with the gcc-4.5-20090813 snapshot, GMP 4.3.1 and MPFR
2.4.1
I have /lib/cpp present (from the cpp package) but no system compilers
installed. Instead I have GCC 4.3.4 elsewhere in my path, but
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-14 10:52 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hp at gcc dot gnu dot org 2009-08-14 10:33 ---
patch posted.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-14 10:33 ---
Can you extract the tests that were failing and add them to the testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41061
--- Comment #24 from uros at gcc dot gnu dot org 2009-08-14 10:31 ---
Subject: Bug 41019
Author: uros
Date: Fri Aug 14 10:31:09 2009
New Revision: 150738
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150738
Log:
PR target/41019
* config/i386/sse.md (SSEMODE124C8
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-14 09:51 ---
Do you have a testcase?
I tried this and static_cast behaves the same as the C-style cast:
int i1 = 0.5;
int i2 = (int)0.5;
int i3 = static_cast(0.5);
Only the first line gives a warning.
--
http://gcc.gnu.org/b
--- Comment #6 from dominiq at lps dot ens dot fr 2009-08-14 09:37 ---
>From comment #5, an easy workaround (better coding practice?) is to rename
PutALine in subroutine Dump_cmd (indeed this does not prevent to fix the
bug!-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41062
See http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00621.html
and follow ups starting at http://gcc.gnu.org/ml/fortran/2009-08/msg00120.html
Without the following patch, there is at least on Win64 a pointer cast warning:
libgfortran/intrinsics/string_intrinsics_inc.c:
- starting = ((unsigned l
a, b } dummy;
int v = a;
char s[b];
Tested as buggy:
GNU C 4.5.0 20090814 (experimental)
GNU C 4.4.2 20090806 (prerelease)
GNU C 4.4.0 20090506 (Red Hat 4.4.0-4)
--
Summary: DW_TAG_enumeration_type+DW_TAG_enumerator is sometimes
missing
Product: gc
--- Comment #11 from ubizjak at gmail dot com 2009-08-14 08:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-14 07:48 ---
Even more reduced example.
In "two" the internal procedure "one" should be called. Additionally, there
exists a generic procedure with the same name "one", which however is not
available in "two" as it is _not_ host-
--- Comment #10 from uros at gcc dot gnu dot org 2009-08-14 07:41 ---
Subject: Bug 8603
Author: uros
Date: Fri Aug 14 07:41:17 2009
New Revision: 150735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150735
Log:
Backport from mainline:
2009-08-11 Uros Bizjak
88 matches
Mail list logo
