This code:
struct foo { typedef int f; };
int main() {
foo g;
typeof(g)::f bar;
typedef
typeof(g) h;
h::f baz;
return 0;
}
gets:
s3:~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:4: error: expected initializer before bar
--
Su
--- Comment #9 from anitha dot boyapati at atmel dot com 2010-03-08 06:04
---
(In reply to comment #5)
> Fails with gcc 4.4.3 and gcc 4.5 with -O1.
>
Correction : The bug passes with 4.4.2 and above versions. Code generated can
be seen below.
func_45:
...
rcall func_1
--- Comment #8 from abnikant at gmail dot com 2010-03-08 05:26 ---
avr-gcc-4.4.0 -S -O1 small.c
code snippet version avr-gcc-4.4.0
.L__stack_usage = 0
rcall func_15
sbiw r24,0
breq .L4
lds r24,g_54
lds r25,g_54+1
lds r26,g_54+2
lds r27,g_54+3
.L4:
sts g_8
--- Comment #7 from abnikant at gmail dot com 2010-03-08 05:22 ---
(In reply to comment #6)
> An observation - the same file when compiled with -O1 for i386 target also
> appears to load g_54 using movl instruction.
>
> _func_45:
> ...
> L11:
> testw %bx, %bx
>
--- Comment #2 from jason at gcc dot gnu dot org 2010-03-08 04:27 ---
and indeed this testcase gets the same crash:
void f()
{
auto val = val;
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from bangerth at gmail dot com 2010-03-08 04:26 ---
What I'm saying is that this entire discussion is already present in PR13687
and that there is nothing more to say. The warning exists in C because it
can lead to hard-to-find bugs in C code because you can call a functio
--- Comment #19 from bangerth at gmail dot com 2010-03-08 04:26 ---
*** Bug 43272 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13687
--- Comment #4 from erh+gcc at nimenees dot com 2010-03-08 04:02 ---
(In reply to comment #3)
> (In reply to comment #2)
> > So does this mean bug #13687 is going to be reopened? Or is there some
> > workaround that hasn't been mentioned?
>
> No. I think the issue has been discussed at
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-03-08 02:53
---
Kai,
Patch in Comment #8 is OK to commit. Thanks!
(I also regression tested on x86-64-linux-gnu.)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jason at gcc dot gnu dot org 2010-03-08 02:37 ---
The code is ill-formed; specifically, the line
auto val = val;
violates 7.1.6.4/3: "The name of the object being declared shall not appear in
the initializer expression."
--
jason at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 01:06 ---
Dup of bug 15272.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43282
--- Comment #5 from bangerth at gmail dot com 2010-03-08 00:36 ---
OK, so the question is whether the testcase in comment #3 should be rejected
based on the wording of 14.6.2/3.
Jason, as our resident language lawyer, would you mind commenting?
W.
--
bangerth at gmail dot com chan
--- Comment #4 from schaub-johannes at web dot de 2010-03-08 00:26 ---
Yes, this is the consequence. You have to add "this->" or "Bar::" to use
another form of lookup (qualified or class-member access) or use a
using-declaration to bring the name in scope ("using HasFoo::foo;").
I can'
--- Comment #3 from bangerth at gmail dot com 2010-03-08 00:19 ---
But that would mean that the following code should be invalid
because the compiler should never find HasFoo::foo even at
instantiation time:
-
template
struct HasFoo {
void foo(T) { }
};
template
st
--- Comment #2 from schaub-johannes at web dot de 2010-03-08 00:01 ---
The point is that the scope of the base class is not examined even during
instantiation, so you cannot find the class member function and ADL finds
A::foo instead. The Standard says at 14.6.2/3:
In the definition of
--- Comment #1 from bangerth at gmail dot com 2010-03-07 23:41 ---
The error message I get is this:
g/x> c++ -c x.cc
x.cc: In member function 'void Bar::bar() [with T = A::Baz]':
x.cc:18: instantiated from here
x.cc:10: error: no matching function for call to 'Bar::foo(A::Baz)'
x.cc:3
--- Comment #2 from ullner at gmail dot com 2010-03-07 22:10 ---
Hm? How does calling std::pow with different types behave differently? The
value can be stored fine if one does "double dValue = std::pow(2.0, 64);long
long llValue = dValue;" // OK
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from schwab at linux-m68k dot org 2010-03-07 22:07 ---
9223372036854775807 has more significant bits than what fits in a double, it is
rounded to 9223372036854775808.0, which then overflows when converted to long
long.
--
schwab at linux-m68k dot org changed:
--- Comment #2 from danglin at gcc dot gnu dot org 2010-03-07 21:44 ---
Breakpoint 1, get_object_alignment (exp=0x7afb80f0, align=8, max_align=64)
at ../../gcc/gcc/builtins.c:320
320 if (TREE_CODE (exp) == CONST_DECL)
(gdb) p debug_tree (exp)
>
side-effects VOID file
/mnt/
When casting a double to a long long causes GCC to overflow the output value.
Imagine;
#include
double foo() { return 9223372036854775807.0; }
int main() {
std::wcout << (long long)foo(); // Prints -9223372036854775808
}
Additionally, std::pow(double, int) and std::pow(double, double) seem to b
--- Comment #34 from hubicka at gcc dot gnu dot org 2010-03-07 20:49
---
Hi,
since this is blocker for a release and I can't reproduce the problem myself,
if there any hope to get a backtrace?
We can also just silence the sanity check for 4.5 for time being, but the
proposed patch shoul
--- Comment #15 from hubicka at gcc dot gnu dot org 2010-03-07 20:37
---
I've been discussing this on IRC a while ago with Richard Guenther, but forgot
to add a record.
It seems that for 4.5, it is best to leave inlining heruistics as it is. THe
code size regression come mainly from b
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 20:13 ---
Unfortunately, we still get the following after back porting the above
change:
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
-O1 -w -c -o pr42559.o
/mnt/gnu/gcc/gcc/gcc/testsuite/gcc
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 19:52 ---
I think -freorder-blocks-and-partition should be suppressed on hppa due
to the way branches are handled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39690
PASS: gcc.dg/lto/20091027-1 c_lto_20091027-1_0.o-c_lto_20091027-1_1.o link
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-O
0 -fwhopr -c -o c_lto_20091216-1_0.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lt
o/20091216-1_0.c(timeout = 300)
PASS: gcc.dg/lto/20091216-
GCC does not accept this code, but is supposed to. "foo" is looked up using
unqualified name lookup, during which dependent base classes are ignored. The
fact that "foo" is dependent must not influence this.
template
struct HasFoo {
void foo() { }
};
// dependent "HasFoo" should be ignored duri
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-07 18:58 ---
How should this test be xfailed? The lto test options don't seem to provide
an xfail mechanism.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41671
--- Comment #17 from mjtruog at fastmail dot ca 2010-03-07 17:53 ---
I have found this doesn't fix the problem. It may fix the problem in the
example, but not in all cases. I have a few new crash dumps:
Core was generated by `_release/lib/cloud-0.0.9/priv/cloud_worker_port'.
Program t
--- Comment #4 from danglin at gcc dot gnu dot org 2010-03-07 17:52 ---
gcc.dg/lto/20090116 fails on hppa64-hp-hpux11.11 as shown in #1.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-07 17:36
---
(In reply to comment #10)
> Cannot we warn for this?
As usual, if we knew the data is not aligned we'd not "miscompile" it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-07 17:24 ---
I just noticed that using -Warray-temporaries gives the warning twice. For the
test in comment #8, I get
[macbook] f90/bug% gfc -Warray-temporaries -fcheck=all pr40850_3.f90
pr40850_3.f90:11.13:
CALL test ((/ line
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-07 16:56 ---
It is caused by revision 148848:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00831.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
--- Comment #10 from manu at gcc dot gnu dot org 2010-03-07 16:17 ---
Cannot we warn for this?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-07 15:59 ---
For the record, the patch in comment #8 does not apply on fortran-dev. AFAICT
the patches in comments #2 and 7 are enough for the branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-07 15:47 ---
Confirmed. This is exposed by the new bswap pass.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-07 15:44 ---
Subject: Bug 43176
Author: jakub
Date: Sun Mar 7 15:44:11 2010
New Revision: 157264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157264
Log:
PR debug/43176
* Makefile.in (var-tracking.o): De
--- Comment #48 from rguenth at gcc dot gnu dot org 2010-03-07 15:35
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #47 from bernds at gcc dot gnu dot org 2010-03-07 15:20 ---
Subject: Bug 42220
Author: bernds
Date: Sun Mar 7 15:20:12 2010
New Revision: 157263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157263
Log:
PR rtl-optimization/42220
* regrename.c (scan_
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-07 14:43
---
Confirmed. This patch:
Fix PR42326: handle default definitions.
2010-03-02 Sebastian Pop
PR middle-end/42326
* sese.c (name_defined_in_loop_p): Return false for default
definitions.
--- Comment #17 from p dot vanhoof at oma dot be 2010-03-07 14:12 ---
The test case in comment #9 has only been fixed on the graphite branch, but
still crashes on the trunk as of r157255. Please reopen and fix this problem on
the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from janus at gcc dot gnu dot org 2010-03-07 14:07 ---
(In reply to comment #7)
> This leaves us with the following regressions:
>
> FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
> FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess e
--- Comment #2 from mark at gcc dot gnu dot org 2010-03-07 13:48 ---
GNU Classpath java.lang.String does have the String(int[] codePoints, int
offset, int count) constructor. But libgcj still has a separate String
implementation that doesn't have this constructor merged.
--
mark at g
it resembles Bug 41896 but with the addition of line: auto val = val;
The code is legal but doesn't make any sense. In some rare cases which I
couldn't replicate simply, it went into an infinite mallo, consuming the whole
memory, instead of segfault.
float nested_lambda()
{
float val;
--- Comment #1 from marcus at mc dot pp dot se 2010-03-07 12:39 ---
Here is a reproduction recipe using Jython 2.5.1, by the way:
chiyo:~/jython2.5.1% gij-4.4 -jar jython.jar
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54)
[GNU libgcj (Free Software Foundation, Inc.)] on java1
--- Comment #2 from edwintorok at gmail dot com 2010-03-07 12:19 ---
Created an attachment (id=20039)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20039&action=view)
preprocessed sha256.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
--- Comment #1 from edwintorok at gmail dot com 2010-03-07 12:19 ---
Created an attachment (id=20038)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20038&action=view)
sha256.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
gcc version 4.5.0 20100307 (experimental) (GCC)
Bug initially reported against openSUSE 11.3 factory's gcc-4.5, but I
reproduced with upstream gcc-4.5 SVN r157262.
See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1862 for the original
report.
--
Summary: gcc4.5 -m3
In the java.lang.String implementation in libjava, there is no
constructor java.lang.String(int[], int, int). This constructor was
added by Sun in 1.5, but since gij claims to be 1.5 it should be there.
The String class in Classpath has the constructor, but it is not used
by gij.
--
48 matches
Mail list logo
