--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-04 07:41 ---
Well, TREE_LIST can mean anything, it is a list used for all kinds of things.
So you shouldn't handle it in dump_expr IMHO, but handle it in
dump_template_argument or dump_template_bindings? Not sure where the TREE_LI
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:32 ---
No error with ifort/NAG f95; g95 has:
Error: Derived variable 'dd' in EQUIVALENCE at (1) contains a component with
a default initialization in a COMMON block
Lahey has:
Common block object 'dd' must not be of type
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:29 ---
NAG f95 and g95 print an error:
Error: USE TEST_MOD in program-unit MY_SUB imports symbol MY_SUB
Error: Module 'test_mod' at (1) redefines the current program unit 'my_sub'
ifort prints nothing by default and wit
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:26 ---
NAG f95:
Error: I is in COMMON - can only initialise in BLOCK DATA
ifort with "-stand f95" (only):
Warning: In Fortran 95, this DATA statement object cannot appear in either a
blank COMMON block or a named COMMON blo
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:24 ---
ifort:
Warning: Continuation character illegal as first non_blank in statement
NAG f95:
Error: Invalid continuation
--
burnus at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:23 ---
g95:
Error: Dummy procedure at (1) not allowed in ELEMENTAL procedure
ifort:
Error: A dum-arg of a procedure with the ELEMENTAL prefix-spec shall not be a
dummy procedure. [F]
PURE INTEGER FUNCTION F(I)
--
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:20 ---
a.f90:19: internal compiler error: in gfc_conv_operator_assign, at
fortran/trans-expr.c:1367
NAG f95:
Error: Non-elemental user-defined assignment in WHERE
--
burnus at gcc dot gnu dot org changed:
Wh
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:16 ---
Interestingly, NAG f95 does not detect this. ifort prints only a warning:
Warning: This entry point does not define all dummy variables used in bounds
or
length expressions of automatic data objects. [S1]
where
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:14 ---
confirm.
NAG f95:
Error: Function reference not allowed in DATA-implied-DO
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-04 07:12 ---
NAG f95 does not even detect this at run time! However, I think it should be
relatively easyly detectable at run time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34656
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-04 07:11 ---
Confirm.
NAG f95 prints:
Error: Element of assumed-shape array A supplied for array argument A (no. 1)
of S2
ifort:
Error: If the actual argument is scalar, the corresponding dummy argument shall
be scalar unless th
--- Comment #2 from jv244 at cam dot ac dot uk 2008-01-04 07:02 ---
(In reply to comment #1)
> This is almost impossible to diagnose. Do you know of any compiler that
> detects this?
I think that lahey detects this at runtime. Almost all compilers detect the
simple case of directly (i.
--- Comment #2 from zhouyi04 at ios dot cn 2008-01-04 06:31 ---
Subject: Re: redundant if expression in
find_conditional_asserts
Hey ubizjak!
Please provide a regression test for me, it is the first time I have a
chance to patch gcc, Thanks a lot :)
Patch against gcc-4.3.0
--- gc
--- Comment #2 from alexey dot starovoytov at gmail dot com 2008-01-04
05:28 ---
ext/pb_ds/regression/trie_data_map_rand.cc
is a self-contained testcase from existing code base.
I couldn't narrow down it further, since all derived testcases produced correct
instantiation of the construc
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-04 05:00
---
Notice in the tree dump that dimmy is already a pointer type when passed into
the subroutine.
Can you try this patch and see if it works and also send me the fdump tree
original?
Index: trans-expr.c
===
--- Comment #39 from mark at codesourcery dot com 2008-01-04 04:43 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
fche at redhat dot com wrote:
>> Downgrading to P4. We seem to have consensus that this is [not] a GCC
>> wrong-code
>> bug.
>
> Yeah, it
--- Comment #5 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 03:31 ---
Of course, if you add the check for the appropriate type of end iterator right
before the find gets called, the problem goes away without a trace.
Btw and imho, the worst thing that find may get as
--- Comment #4 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 03:30 ---
Created an attachment (id=14873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14873&action=view)
THIS is the working, 32bit, older compiler generated version.
Forgot to add -save-temps after
--- Comment #38 from fche at redhat dot com 2008-01-04 03:19 ---
(In reply to comment #37)
> Downgrading to P4. We seem to have consensus that this is [not] a GCC
> wrong-code
> bug.
Yeah, it seems to be a mistaken expectation of -ffreestanding not to
call libgcc. Maybe a new option
--- Comment #3 from nam3l3ss dot bugreportaccount at gmail dot com
2008-01-04 02:57 ---
Created an attachment (id=14872)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14872&action=view)
This is the working, 32bit, older compiler generated version.
--
http://gcc.gnu.org/bugzil
--- Comment #8 from pcarlini at suse dot de 2008-01-04 02:32 ---
Hi Doug. Wanted to start updating parts of , and, as expected, with
straightforward rvalue reference changes I can compile the functior1 case.
However, I'm not clear about the int (test_type::*)() case, which is indeed
fail
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-04 01:47
---
I will have a re-go at this again.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pcarlini at suse dot de 2008-01-04 01:29 ---
Please provide a short, self-contained testcase, not using any ext header.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-04 00:47 ---
This is true for normal reference types too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34666
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-04 00:46 ---
It is just accepted at parsing time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34666
The following code will not compile even if the error message doesn't make
sense, because it obviously knows which member to instantiate.
This may be a compiler bug issue, or and ambiguous error message.
#include
using namespace std;
template
class vector
{
vector();
p
$ cat bug.cpp
template < typename T >
struct X
{
X( X const&& o )
{
o.f(); // <-- accepted.
}
int f();
};
struct Y
{
Y( Y const&& o )
{
o.f(); // <-- rejected.
}
int f();
};
$ /opt/gcc43/bin/
--- Comment #2 from pcarlini at suse dot de 2008-01-04 00:28 ---
Seems just matter of handling TREE_LIST in dump_expr (i.e., forwarding to
dump_type)
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-04 00:16 ---
Subject: Bug 34457
Author: tromey
Date: Fri Jan 4 00:14:31 2008
New Revision: 131311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131311
Log:
gcc/
PR c/34457:
* c-common.c (c_type_hash): Ha
--- Comment #4 from tromey at gcc dot gnu dot org 2008-01-04 00:14 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-03 23:28 ---
Confirmed, this is relatively easy to catch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from spop at gcc dot gnu dot org 2008-01-03 23:04 ---
Reverted the fix.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|RES
--- Comment #16 from spop at gcc dot gnu dot org 2008-01-03 23:01 ---
Subject: Bug 34458
Author: spop
Date: Thu Jan 3 22:59:48 2008
New Revision: 131308
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131308
Log:
2008-01-03 Sebastian Pop <[EMAIL PROTECTED]>
Revert fix
--- Comment #15 from rakdver at gcc dot gnu dot org 2008-01-03 22:22
---
(In reply to comment #14)
> Fixed.
The fix looks a bit ugly. tree-data-ref should probably use double_ints or
mpz, instead (although this cleanup is obviously for 4.4).
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #14 from spop at gcc dot gnu dot org 2008-01-03 22:03 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from spop at gcc dot gnu dot org 2008-01-03 22:01 ---
Subject: Bug 34458
Author: spop
Date: Thu Jan 3 21:59:38 2008
New Revision: 131307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131307
Log:
2008-01-02 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-op
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-03 21:59 ---
The bug appeared with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129391
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34611
--- Comment #3 from dcb314 at hotmail dot com 2008-01-03 21:52 ---
(In reply to comment #1)
> I always hated this warning from the EDG front-end, it sometimes produces a
> false warning.
Feel free to send a bug report to EDG.
Like I said, I checked each one and I agree with Intel C 10
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-03 21:51 ---
This is almost impossible to diagnose. Do you know of any compiler that
detects this?
The only way I see to diagnose this, is to mark all do loop variables as such,
and warn about all assignments to such variables i
--- Comment #2 from dcb314 at hotmail dot com 2008-01-03 21:51 ---
Created an attachment (id=14871)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14871&action=view)
patch for gcc 4.3 20071228
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34592
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-01-03 21:41
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-01-03 21:25
---
Subject: Bug 31081
Author: hubicka
Date: Thu Jan 3 21:23:26 2008
New Revision: 131306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131306
Log:
PR tree-optimization/31081
* tree-inline.c
--- Comment #8 from rakdver at gcc dot gnu dot org 2008-01-03 21:23 ---
(In reply to comment #7)
> The final tree IL looks good, so I suspect the RTL loop optimizer gets this
> wrong.
>
> add r1, sp, #56 // upper loop-bound; should have been #12
> I actually wanted to say 'should
--- Comment #4 from hubicka at ucw dot cz 2008-01-03 21:05 ---
Subject: Re: [4.3 regression] ICE with "-fprofile-arcs -fopenmp"
> (which compiles) profile counters are added before omp expansion and once
> again
> for the child function. Is there a reason why pass_tree_profile can't
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
CONTAINS
SUBROUTINE S1(a)
real, dimension(:) :: a
call s2(a(1))
END SUB
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
INTEGER :: i(10)
DATA (i(MODULO(j,5)),j=1,4) /4*0/
END
--
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
SUBROUTINE S1(I)
CHARACTER(LEN=I+J) :: a
ENTRY E1(J)
END SUB
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
MODULE M1
TYPE T1
INTEGER :: I(3)
END TYPE T1
TYPE(T1), PARAMETE
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
MODULE M1
IMPLICIT NONE
TYPE T1
INTEGER :: I
END TYPE T1
INTERFACE
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
MODULE M1
IMPLICIT NONE
CONTAINS
PURE ELEMENTAL SUBROUTINE S1(I,F)
INTEG
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
&
end
--
Summary: corner case continuation line
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
COMMON /A/ I
INTEGER :: I=1
END
--
Summary: sav
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
module test_mod
interface
subroutine my_sub (a)
real a
end subr
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
PROGRAM test
IMPLICIT NONE
INTEGER :: i
DO i=1,100
CALL do_somethi
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
! 5.5.2.5
TYPE data_type
SEQUENCE
INTEGER :: I=7
END TYPE data_type
IN
The following is non-standard and the compiler should probably generate a
warning/error with '-pedantic -std=f95', but does not do so with
gcc version 4.3.0 20080103 (experimental) [trunk revision 131300] (GCC)
CHARACTER :: a(3)
WRITE(a) 0 ! no unformatted on interna
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-03 20:00 ---
(In reply to comment #3)
> Patch.
Looks obvious and simple.
OK to commit if it passes regression-test.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34557
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-03 19:53 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-03 19:50 ---
Subject: Bug 34565
Author: tkoenig
Date: Thu Jan 3 19:49:38 2008
New Revision: 131305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131305
Log:
2008-01-03 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #1 from dean at arctic dot org 2008-01-03 19:27 ---
oops i should have used an "unsigned long" for the tag rather than unsigned
long long, not that it matters much.
here's an expanded example showing another unnecessary REX:
extern unsigned long table[];
unsigned long foo(
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
for this code:
extern unsigned long table[];
unsigned long foo(unsigned char *p) {
unsigned long long tag = *p;
return table[tag >> 4];
}
gcc generates:
:
0: 0f b6 07movzbl (%rdi),%eax
3: 48 c1 e8 04 shr$0x4,%rax
7: 48 8b 04 c5
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-03 18:58 ---
The final tree IL looks good, so I suspect the RTL loop optimizer gets this
wrong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from saurabh dot verma at celunite dot com 2008-01-03 18:36
---
Patch submitted.
Pending approval/commit.
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00046.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17943
--- Comment #1 from tbm at cyrius dot com 2008-01-03 18:27 ---
This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't
happen with EABI.
--
tbm at cyrius dot com changed:
What|Removed |Added
-
[ Forwarded from http://bugs.debian.org/458745 ]
Camm Maguire <[EMAIL PROTECTED]>
arm-only miscompilation of alloca code
i386:
cc -g /tmp/foo.c -o /tmp/foo
/tmp/foo
0xbf867bd0
0x1
0x2
0x3
arm:
cc -g foo.c -o foo
./foo
0x18beed5d
Segmentation fault
Testcase:
#include
#include
#include
#defin
--- Comment #6 from tbm at cyrius dot com 2008-01-03 18:22 ---
(In reply to comment #2)
> I see different IL for 4.2 compared to 4.3, is the bug present in 4.3? Can
> you
> attach the optimized tree dump?
I also get a segfault with the testcase and 4.3.0 20070916.
The original progra
--- Comment #3 from dberlin at gcc dot gnu dot org 2008-01-03 18:16 ---
It is never okay to base an existing expression on an SSA_NAME alone, which is
why we avoid it.
If the SSA_NAME was available, it would have been in the AVAIL set and been
found by the "find" part of find_or_generat
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-03 18:09 ---
Related to PR19407 I guess. CCing Jason.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-03 18:08 ---
Testing my patch on mainline.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
tbm at cyrius dot com changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
--- Comment #5 from tbm at cyrius dot com 2008-01-03 18:07 ---
Created an attachment (id=14870)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14870&action=view)
optimized tree dump (4.2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
--- Comment #4 from tbm at cyrius dot com 2008-01-03 18:03 ---
Bugzilla wraps the testcase in a way that some commented out is no longer
commented out and so you don't see the segfault. Here's the testcase again
with proper wrapping:
typedef unsigned short u16;
typedef unsigned char u8
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-03 17:59 ---
Subject: Bug 34602
Author: tromey
Date: Thu Jan 3 17:58:26 2008
New Revision: 131304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131304
Log:
libcpp
PR preprocessor/34602.
* directives.c (d
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-03 17:59 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-03 17:58 ---
I'm taking a look at how it might be done.
This allows compilation to proceed:
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(rev
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-01-03 17:48
---
I am not going to work on this anymore.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-01-03 17:47
---
I am getting tried of pinging this patch, I guess if nobody wants to comment
that is up to them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-03 17:46 ---
I do have a correct patch which I will submit when stage1 comes around.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-01-03 17:44
---
I am not going to be able to get this done for 4.2.x so unassigning.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-03 17:43 ---
Not going to happen any time soon so unassigning. CCing the objective-C
maintainer.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-01-03 17:42
---
(In reply to comment #11)
> So, did you have time? :-)
Maybe this weekend :). I guess I have been really behind on my FSF bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-03 17:42 ---
Created an attachment (id=14869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14869&action=view)
gcc43-pr34609.patch
I'll be testing attached patch. This works without -ftest-coverage, as
function
is cleaned u
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-03 17:41 ---
This is harder to do than I expected, the minimal toc register is used while
doing reload and using a psedu-register there causes reload to use a memory
location.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-01-03 17:40
---
I am not going to patch 4.2 and before for this, I will let someone else do it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-03 17:29 ---
Confirmed. While I have a patch to make VN handle the case of type-punning
constants, making it to generate VIEW_CONVERT_EXPRs instead runs into the
principle barrier that FRE does not do insertion.
The patch looks
--- Comment #1 from tbm at cyrius dot com 2008-01-03 17:18 ---
Created an attachment (id=14868)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14868&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34651
I get the following ICE with trunk from 20071212 on hppa (but not
on x86_64):
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -Wno-multichar -O2
libgtkol-cmenu.ii
cmenu.cpp: In member function 'virtual void
CMenuItem::Serialize(CXMLElementNode*&, int)':
cmenu.cpp:551: internal compiler erro
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-03 17:10
---
Ian, Eric? Any advice on the bitfield stuff as of comments 7/9?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-01-03 17:06
---
With optimization we now avoid the error, but unoptimized code is still wrong:
_Z10InitializeP16SQLU_DICT_INFO_0:
.LFB3:
pushq %rbp
.LCFI2:
movq%rsp, %rbp
.LCFI3:
pushq %rbx
.LCFI4:
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-01-03 17:02
---
A user that has turned on C++0x will of course not see the message that ISO C++
doesn't allow variadic templates. Our NEWS file is going to say that we have a
great new feature: variadic templates. Given that, it
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-03 16:48 ---
This is obviously an error in your program or LGraph as you can see
#2 0x00402cb3 in std::find<__gnu_cxx::__normal_iterator const*, std::vector,
std::allocator > > >, int> (__first={_M_current =
0x0}, __las
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-03 16:43 ---
(In reply to comment #6)
> The problem is that cshift0's target-independent function type says that the
> SHIFT and DIM arguments are integers, rather than pointers to integers.
Indeed. Thanks Richard! The dump has:
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-01-03 16:26
---
4.0.0 really did not work either, it just did not cause a crash as the checks
for invalid gimple was not there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-03 16:23 ---
I don't have time to work on this any more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-03 16:23 ---
I will test the following
bool
is_gimple_min_invariant (const_tree t)
{
switch (TREE_CODE (t))
{
case ADDR_EXPR:
/* We do not allow arbitrary invariant expressions as gimple
such as &a[1 - &
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-01-03 16:23
---
This was caused by the patch which fixed PR 20280 and the 2nd iteration of the
patch was rejected so unassigning from me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from ubizjak at gmail dot com 2008-01-03 16:10 ---
(In reply to comment #0)
> /*gcc/tree-vrp.c */
>
> 3603 static bool
> 3604 find_conditional_asserts (basic_block bb, tree last)
> 3605 {
> ...
>if (e->dest == bb)
> 3623 continue;
> ...
> 3652
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-03 16:01 ---
I agree, these sort of bugs should be P4 as a user will only see
t.C:1: error: ISO C++ does not include variadic templates
t.C:3: confused by earlier errors, bailing out
--
http://gcc.gnu.org/bugzilla/show_bug.
1 - 100 of 141 matches
Mail list logo
