[Bug c/50284] possible miscompilation with -fstrict-aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-04
08:57:35 UTC ---
(In reply to comment #4)
(In reply to comment #3)
struct Value {
struct jsval data;
};
...
struct jsval y = t3.array[i];
struct Value *z = (struct Value*)y;
if (z-data.tag == 0xFF85) {
that's invalid in GCCs reading of 6.5 p7. jsval is a subset of Value's
alias-set
but not the other way around. GCC reads z-data.tag as an access to an
object of type Value which is invalid.
So downcast (i.e. casting to a more specialized type) are invalid even if
original data type is correct (not that it is in the reduced testcase)? That
is
really strict :-(
No, if there is an object of dynamic type Value at y then the code is valid.
But you've stored to *y via an lvalue of type jsval and are reading from
it via an lvalue of type Value.
The contorted reasoning is that the pointer conversion invokes undefined
behavior. Definitely an interesting blog post ;)
is there any hope that gcc could be made a bit less strict? Either reading the
member access as not involving an access to the full object or accepting
downcasts (when the original type matches) would work. My preference would be
for the second option, as downcasts are fairly common in OO.
Well, if we allow this case then we can drop any advanced TBAA we do
completely. This restriction is really fundamental to TBAA based
optimizations.
Otherwise consider
int i;
struct X { int k; };
int foo(struct X *p)
{
i = 0;
p-k = 1;
return i;
}
and we couldn't be sure that p-k is not accessing i and thus not optimize
the above to return 0. That would be very bad.
You have -fno-strict-aliasing to save you.
Your better testcase doesn't change anything - you've just changed the
type of an unrelated object.
[Bug tree-optimization/50287] [4.7 Regression] FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c compilation, -O2 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50287 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz Target Milestone|--- |4.7.0 Summary|FAIL: |[4.7 Regression] FAIL: |gcc.c-torture/execute/built |gcc.c-torture/execute/built |ins/vsnprintf-chk.c |ins/vsnprintf-chk.c |compilation, -O2 -flto |compilation, -O2 -flto --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-04 08:57:37 UTC --- It seems we are creating an SSA name for a non-register variable. We can't do this. In fact if we encounter an unused param we'd like to pass to the split part we need to pass it in non-SSA form.
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 --- Comment #5 from irar at gcc dot gnu.org 2011-09-04 09:22:42 UTC --- Author: irar Date: Sun Sep 4 09:22:38 2011 New Revision: 178508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178508 Log: PR tree-optimization/50208 * tree-vect-patterns.c (vect_handle_widen_mult_by_const): Add an argument. Check that def_stmt is inside the loop. (vect_recog_widen_mult_pattern): Update calls to vect_handle_widen_mult_by_cons. (vect_operation_fits_smaller_type): Check that def_stmt is inside the loop. Added: trunk/gcc/testsuite/gcc.dg/vect/no-fre-pre-pr50208.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-patterns.c
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #15 from janus at gcc dot gnu.org 2011-09-04 10:46:15 UTC --- I should probably take this one. There was a patch posted at http://gcc.gnu.org/ml/fortran/2011-09/msg1.html which I am about to commit.
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #16 from janus at gcc dot gnu.org 2011-09-04 10:49:18 UTC --- Author: janus Date: Sun Sep 4 10:49:13 2011 New Revision: 178509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178509 Log: 2011-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/50227 * trans-types.c (gfc_sym_type): Check for proc_name. 2011-09-04 Janus Weil ja...@gcc.gnu.org PR fortran/50227 * gfortran.dg/class_45a.f03: New. * gfortran.dg/class_45b.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_45a.f03 trunk/gcc/testsuite/gfortran.dg/class_45b.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from janus at gcc dot gnu.org 2011-09-04 10:50:22 UTC --- Fixed with r178509. Closing. Thanks for the report, Andrew!
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-09-04 10:58:58 UTC --- Fixed.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #33 from Marc Glisse marc.glisse at normalesup dot org 2011-09-04 11:03:41 UTC --- And if you don't like errors saying that X can't be converted to X, you'll need something like the below. I don't think I'll go much further anytime soon (if someone else wants a go, that'd be great...). --- cp/error.c (revision 178506) +++ cp/error.c (working copy) @@ -805,6 +805,8 @@ pp_cxx_cv_qualifier_seq (cxx_pp, class_of_this_parm (t)); else pp_cxx_cv_qualifier_seq (cxx_pp, t); + if (TREE_CODE (t) == FUNCTION_TYPE TYPE_MINVAL (t)) + pp_string (cxx_pp, extern \C\); dump_exception_spec (TYPE_RAISES_EXCEPTIONS (t), flags); dump_type_suffix (TREE_TYPE (t), flags); break;
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 11:18:23
UTC ---
(In reply to comment #12)
bootstrapped with your amended change to rs6000.c
./gcc/xgcc -Bgcc ../tests/hello.c -o hc -fstack-check -save-temps
-fverbose-asm
-fdump-rtl-all
... shows that the stack check is present and correct ...
any idea what test would produce the stack range check?
You'd need to define STACK_CHECK_STATIC_BUILTIN to 1 for PowerPC/Darwin and
have a large frame.
re-bootstrapped (less Ada and Java) with that ...
... checked manually with a cooked-up testcase that we get:
(insn 683 682 684 (set (reg:SI 12 r12)
(unspec_volatile:SI [
(reg:SI 12 r12)
(reg:SI 0 r0)
] UNSPECV_PROBE_STACK_RANGE)) ../test-ppc/limit-struct.c:21 441
{probe_stack_rangesi}
(nil))
for a large frame ... and:
(insn 30 4 31 (set (mem/v:SI (plus:SI (reg/f:SI 1 r1)
(const_int -12368 [0xcfb0])) [0 S4 A8])
(unspec [
(const_int 0 [0])
] UNSPEC_PROBE_STACK)) ../test-ppc/limit-struct.c:93 440
{probe_stack}
(nil))
for a smaller frame ...
... and the asm looks sensible...
... running check again ... but I'd hazard that this is fairly safe (at least,
from the darwin perspective). However, I'm not able to check ppc linux here,
as things stand.
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-04 13:02:15 UTC --- for a smaller frame ... and the asm looks sensible... Great, thanks. Defining STACK_CHECK_STATIC_BUILTIN to 1 for Darwin would be a separate thing. In particular, you'd need to test Ada to validate this change. ... running check again ... but I'd hazard that this is fairly safe (at least, from the darwin perspective). However, I'm not able to check ppc linux here, as things stand. I'll give it a whirl on PowerPC/Linux.
[Bug debug/50279] [4.7 Regression] ICE while building the go front-end with LTO enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50279 Steffen Möller steffen_moeller at gmx dot de changed: What|Removed |Added CC||steffen_moeller at gmx dot ||de --- Comment #1 from Steffen Möller steffen_moeller at gmx dot de 2011-09-04 13:08:36 UTC --- The same error occurs while compiling the Debian package autodocksuite from sid with LTO enabled: /usr/lib/gcc-snapshot/bin/g++ -Wall -g -flto -O2 -Winline -finline-functions -Wl,--as-needed -flto -o autogrid4 autogrid4-main.o autogrid4-check_size.o autogrid4-setflags.o autogrid4-timesys.o autogrid4-timesyshms.o autogrid4-printhms.o autogrid4-prHMSfixed.o autogrid4-printdate.o autogrid4-strindex.o autogrid4-banner.o autogrid4-gpfparser.o autogrid4-parsetypes.o autogrid4-atom_parameter_manager.o autogrid4-read_parameter_library.o autogrid4-parse_param_line.o autogrid4-distdepdiel.o -lm In file included from setflags.cpp:142:0, from :118: main.cpp: In function 'main': main.cpp:2542:1: internal compiler error: in splice_child_die, at dwarf2out.c:5007 Please submit a full bug report, with preprocessed source if appropriate. $ /usr/lib/gcc-snapshot/bin/g++ --version g++ (Debian 20110816-1) 4.7.0 20110816 (experimental) [trunk revision 177785] Sorry for not isolating the problem more. The problem could not be observed in g++ 4.6.1 from Debian unstable (4.6.1-8). It fails later, hence the installation of the snapshot :) Without the LTO, everything is fine.
[Bug testsuite/50023] FAIL: gcc.dg/graphite/id-pr46845.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50023
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-04
13:28:06 UTC ---
The test succeeds with the following patch
--- ../_gcc_clean/gcc/testsuite/gcc.dg/graphite/id-pr46845.c2010-12-15
15:27:24.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/id-pr46845.c2011-09-04 15:18:55.0
+0200
@@ -1,4 +1,4 @@
-/* { dg-options -O2 -ffast-math -fgraphite-identity -w -Wno-psabi { target {
i?86-*-* x86_64-*-* } } } */
+/* { dg-options -O2 -ffast-math -fgraphite-identity -w -Wno-psabi { target {
i?86-*-* x86_64-*-* powerpc*-*-* } } } */
typedef float V2SF __attribute__ ((vector_size (128)));
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 15:28:45 UTC --- (In reply to comment #14) Defining STACK_CHECK_STATIC_BUILTIN to 1 for Darwin would be a separate thing. In particular, you'd need to test Ada to validate this change. indeed, lucky I finally figured out how to get Ada to bootstrap on powerpc-darwin9 then ;-) (FTR, STACK_CHECK_STATIC_BUILTIN is OK on i686-darwin9 and x86-64-darwin10 is running) ... running check again ... ... the tests were OK with the c-family + fortran (STACK_CHECK_STATIC_BUILTIN + comment 12). I'm about to reg-strap w/Ada java to check various WIP.. (long job, don't expect an answer today) ..
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-04 17:29:37 UTC --- (In reply to comment #13) Created attachment 25177 [details] import-export.diff Just the import/export changes, i.e. outside libgo directory. This change is darwin-centric. Peter O'Gorman suggests something along the lines of... just use a gnu make conditional, since gcc requires gnu make to build anyway, check if $OTOOL is != e.g. ifeq($(OTOOL),) ... use objcopy else .. use otool ..endif
[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804 leopardboy2 at yahoo dot com changed: What|Removed |Added CC||leopardboy2 at yahoo dot ||com --- Comment #27 from leopardboy2 at yahoo dot com 2011-09-04 18:02:22 UTC --- I had the same failure on GCC 4.6 ( 4.6 branch as of 9/03/2011) cross building for m68k. I added the proposed patch from above and rebuilt GCC and it fixed it... Can this fix get put into the 4.6 branch also?
[Bug c++/50285] no known conversion for argument 1: 'X' to 'X'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50285
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011-09-04
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-04
18:06:54 UTC ---
An error message is not a bug, please follow the bug reporting instructions and
provide source code for a testcase demonstrating your problem:
http://gcc.gnu.org/bugs/
The message clearly isn't about converting a type to itself, it's about
converting a type to a non-const lvalue reference to that type (X is not the
same as X)
I assume it means you're trying to pass an rvalue (e.g. a temporary) to a
function that requires an lvalue
e.g. this produces a similar error
struct X {
X operator=(X);
};
X f();
void g()
{
X x;
x = f();
}
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #15 from Anders F Björklund afb at users dot sourceforge.net 2011-09-04 18:14:48 UTC --- The whole patch is Darwin-centric, in that it's only applied on Darwin. You are right that it first needs to be conditionalized to go upstream. afaik, $(OTOOL) would be something like missing-otool on e.g. Linux ? (just as we now get $(OBJCOPY) set to missing-objcopy on Mac OS X...)
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-04
18:45:24 UTC ---
The problem is is your code, not gcc
The type of T4::f is void(T2::*)() not void(T4::*)() so when you cast the
pointer to void(T4::*)() you are not casting back to the original type.
You can fix the code by using reinterpret_castvoid(T2::*)() for the cases
that use the expression T4::f, instead of reinterpret_castvoid(T4::*)()
For what it's worth, clang gives exactly the same result as g++ for a reduced
version of your program:
// define class N with no member,
// we just need a type void(N::*)() of which an object can hold a
pointer-to-member-function
class N {} ;
// define class T1 T3 with some member data/functions
// so that an object of class T4 which derives from T1 T2 T3
// will has its base object of type T2 have different address from the object
itself.
class T1
{
public:
char c ;
int i ;
} ;
class T3:virtual public T1
{
public:
int i3 ;
public:
virtual void f2() {
__builtin_printf(Foo3 !! this=%p\n, (void*)this);
} ;
} ;
// define class T2
// T2 has a memmber function f, which our pointer-to-member-function will point
to.
// as T4 derives from T2 as a public base type, this function is an accessable
from T4 ;
// the function outputs the value of 'this' pointer, which i expect it always
points to an object of T2.
class T2
{
public:
int i2 ;
public:
virtual void f() {
__builtin_printf(Foo2 !! this=%p\n, (void*)this);
} ;
} ;
// define class T4, which simply derives from T1T2T3
class T4:public virtual T1, public T3, public T2
{} ;
int main(int, char**)
{
T4 t4 ;
void (N::*pfn)() = 0;
void(T4::*pf4)() = T4::f ;
// this line shows the address of t4 and its base object t4.t2 differ ;
__builtin_printf(AddressOf t4=%p, t4.t2=%p\n, (void*)(t4),
(void*)((T2)(t4)));
{
__builtin_printf(\nwhat i expect:\n);
// the following lines show what i expect to see:
// no matter what form the function call is, the function tells me the
address of t4.t2
t4.f() ;
(t4.*(T4::f))() ;
(t4.*pf4)() ;
}
{
__builtin_printf(\nTestCase1:\n);
__builtin_printf(pfn assignment: pfn =
reinterpret_castvoid(N::*)()(T4::f) \n);
__builtin_printf(Function call form: (t4.*reinterpret_castvoid(T4::*)()(
pfn )() \n);
// Case1:
// pfn is assigned directly from T4::f,
// but actually, its value shows that is T2::f
pfn= reinterpret_castvoid(N::*)()(T4::f) ;
// comparing with the result i memtioned above, this is not what i want.
(t4.*reinterpret_castvoid(T4::*)()(pfn))() ;
}
{
__builtin_printf(\nTestCase2:\n);
__builtin_printf( pfn assignment: pfn =
reinterpret_castvoid(N::*)()(pf4) \n);
__builtin_printf(Function call form: (t4.*reinterpret_castvoid(T4::*)()(
pfn )() \n);
// Case2: pfn is transfromed from pf4, which is defined as type
void(T4::*)(), and its value
// has been correctly assigned as T4::f, not T2::f
pfn = reinterpret_castvoid(N::*)()(pf4) ;
// this time, the function call works correctly
(t4.*reinterpret_castvoid(T4::*)()(pfn))() ;
}
{
__builtin_printf(\nTestCase3:\n);
// Case3:
// this case exactly follows the standered draft, if anyone might say
// in the above casese i used a lvalue(pfn),
// this time, i have rvalue only, but it's obviously not functioning.
__builtin_printf(Function call form: (t4.*reinterpret_castvoid(T4::*)()(
reinterpret_castvoid(N::*)()(T4::f)))() \n);
(t4.*reinterpret_castvoid(T4::*)()(
reinterpret_castvoid(N::*)()(T4::f)
))() ;
}
}
When the 1st and 3rd tests are altered to use reinterpret_castvoid(T2::*)()
it gives the results you expect
so I think this is invalid
[Bug fortran/50288] New: FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288 Bug #: 50288 Summary: FAIL: gfortran.dg/class_45b.f03 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ja...@gcc.gnu.org On Linux/x86, revision 178509: http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00120.html gave: FAIL: gfortran.dg/class_45b.f03 -O1 (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -O2 (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -O3 -fomit-frame-pointer (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -O3 -g (test for excess errors) FAIL: gfortran.dg/class_45b.f03 -Os (test for excess errors)
[Bug debug/49901] gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 18:50:13 UTC --- Author: iains Date: Sun Sep 4 18:50:09 2011 New Revision: 178510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178510 Log: PR debug/49901 * config/darwin.h (DEBUG_MACRO_SECTION): New macro. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h
[Bug debug/49901] gfortran.dg/debug/[pr35154-dwarf2.f/pr37738.f] failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49901 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 18:50:50 UTC --- thus, should be fixed.
[Bug fortran/50278] [4.7 Regression] SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50278 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-04 18:51:33 UTC --- Fixed as of revision 178501.
[Bug fortran/50288] FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-04
19:18:00 UTC ---
I think I understand what's happening, although I don't know how to fix it:
(1) gfortran.dg/class_45a.f03 is compiled and generate g_nodes.mod,
(2) gfortran.dg/class_45b.f03 is compiled and run with -O0,
(3) g_nodes.mod is cleaned due to ! { dg-final { cleanup-modules G_Nodes }
}
(4) gfortran.dg/class_45b.f03 is proceeded with -O1 but g_nodes.mod is no
longer there, hence the failure:
Fatal Error: Can't open module file 'g_nodes.mod' for reading at (1): No such
file or directory^M
FAIL: gfortran.dg/class_45b.f03 -O1 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/gfortran.dg/class_45b.f03:9:6: Fatal Error: Can't
open module file 'g_nodes.mod' for reading at (1): No such file or direc
tory
[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49594 --- Comment #11 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 19:17:29 UTC --- Author: iains Date: Sun Sep 4 19:17:25 2011 New Revision: 178511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178511 Log: PR libffi/49594 * src/powerpc/darwin_closure.S (stubs): Make the stub binding helper reference track the architecture pointer size. Modified: branches/gcc-4_6-branch/libffi/ChangeLog branches/gcc-4_6-branch/libffi/src/powerpc/darwin_closure.S
[Bug fortran/50288] FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-04 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-04 19:18:48 UTC --- Indeed I confirm!-)
[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49594 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 19:19:43 UTC --- Author: iains Date: Sun Sep 4 19:19:39 2011 New Revision: 178512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178512 Log: PR libffi/49594 * src/powerpc/darwin_closure.S (stubs): Make the stub binding helper reference track the architecture pointer size. Modified: trunk/libffi/ChangeLog trunk/libffi/src/powerpc/darwin_closure.S
[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49594 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2011-09-04 19:20:38 UTC --- fixed on trunk and 4.6.
[Bug fortran/50288] FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-04
19:54:56 UTC ---
An evil trick would be the following, which causes a run once:
--- a/gcc/testsuite/gfortran.dg/class_45b.f03
+++ b/gcc/testsuite/gfortran.dg/class_45b.f03
@@ -1 +1 @@
-! { dg-do run }
+! { dg-do run }
[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #21 from Marc Glisse marc.glisse at normalesup dot org 2011-09-04 20:08:49 UTC --- Since I went through the same thing recently: (In reply to comment #0) ENUM_BITFIELD mixes integers and enums. Fix: #if (GCC_VERSION 2000) #define ENUM_BITFIELD(TYPE, NAME, SIZE) __extension__ enum TYPE NAME : SIZE #elif defined(__cplusplus) #define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME #else #define ENUM_BITFIELD(TYPE, NAME, SIZE) unsigned int #endif Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00758.html some problem with obstack_free, I didn't investigate. Maybe substraction involving void* NULL or 0? Fix, obstack.h before: Before: # define obstack_free(h,obj)\ ( (h)-temp = (char *) (obj) - (char *) (h)-chunk,\ After, add cast to char*: # define obstack_free(h,obj)\ ( (h)-temp = (char *) ((char*)(obj)) - (char *) (h)-chunk,\ Bug in sunpro, reported and fixed in the development version (but possibly not for 12.3). There are also problems then compiling gmp in tree. I had to remove its #include iosfwd on Solaris because that pulled in locale and there was some problem. Maybe due to local hacks? I removed all the locale stuff from my gcc/gmp. CC is not a standard C++ compiler, you have to add -library=stlport4 to get it to even try. (In reply to comment #1) also lots of warnings about mixing extern C and not: Seems ok to ignore those that are only warnings. and other errors related, mixing said in ternary, like: foo = foo2 ? foo2 : foo3; (as in reallocator = set-reallocator ? set-reallocator : xrealloc) where foo2 and foo3 vary in extern C-ness. workaround is foo = foo2 if (!foo) foo = foo3 even though that doesn't seem different enough -- I understand there is the problem of figuring out a type for the ternary operator, but there is also the matter of being able to assign the function pointers This one is also Bug 50177. There is also Bug 50167. here's an example of the obtack_free problem, either I didn't get all the obstack.h files fixed or the cast needs to be void* or something: ../../gcc-4.5/libcpp/files.c, line 1193: Error: Cannot assign char* to int. Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00758.html (In reply to comment #7) rtl.c, change: #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) sizeof FORMAT - 1 , to: #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) sizeof (FORMAT) - 1 , seems to work. Seems preferable too. Bug in sunpro, reported and fixed in the development version (but possibly not for 12.3).
[Bug fortran/50288] FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-04
20:35:36 UTC ---
An evil trick would be the following, which causes a run once: ...
It works, but I think if this trick is used, it should be documented as in
gcc/testsuite/gfortran.dg/cray_pointers_2.f90:
! Using two spaces between dg-do and run is a hack to keep gfortran-dg-runtest
! from cycling through optimization options for this expensive test.
Another working possibility is to remove the line
! { dg-final { cleanup-modules G_Nodes } }
from gfortran.dg/class_45b.f03 and add an empty cleaning test:
cat ./gcc/testsuite/gfortran.dg/class_45c.f03
! { dg-do run }
!
! PR 50227: [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
!
! Contributed by Andrew Benson aben...@caltech.edu
program Test
end program Test
! { dg-final { cleanup-modules G_Nodes } }
Note that it will be impossible to test gfortran.dg/class_45b.f03 alone.
[Bug fortran/50288] FAIL: gfortran.dg/class_45b.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50288
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-04
21:19:31 UTC ---
I think one problem is that
! { dg-additional-sources class_45a.f03 }
compiles the additional source *after* the main file. That's not trivially
fixable as the library part of $options needs to come after the files - thus,
one would need a new global variable, which is then used before $file in the
compiler execution.
(In reply to comment #4)
An evil trick would be the following, which causes a run once: ...
A better way is the following patch, which adds dg-do run-once, which should
then also be applied to cray_pointers_2.f90. I think a dg-do run-once is also
useful to tests of libgfortran for which running a test case multiple times is
just a waste for time. One still should add a comment in class_45{a,b}.f90 to
denote this nonobvious file dependency.
--- a/gcc/testsuite/lib/gfortran-dg.exp
+++ b/gcc/testsuite/lib/gfortran-dg.exp
@@ -104,7 +104,9 @@ proc gfortran-dg-runtest { testcases default-extra-flags }
{
# look if this is dg-do-run test, in which case
# we cycle through the option list, otherwise we don't
- if [expr [search_for $test dg-do run]] {
+ if [expr [search_for $test dg-do +run-once]] {
+ set option_list [list { -O } ]
+ } elseif [expr [search_for $test dg-do +run]] {
set option_list $torture_with_loops
} else {
set option_list [list { -O } ]
[Bug target/50281] result registers are overwritten giving incorrect result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50281 --- Comment #10 from NickParker at Eaton dot com 2011-09-04 21:22:30 UTC --- Richard, 'bogus' isnt a technical term I'm familiar with - I'm not entirely sure what you mean, however, I have found the problem with my ASM code. If you'll notice I am adding partial products to r4,r5,r6,r7 without them ever being initialised. What was missing was initialistion of the temporary result registers r4,r5,r6,r7 where I am generating my result. After adding these initialisatons, and also a few movw's for a few less cycles in a couple of places, the code now works correctly. Thanks for your input and sorry that I made a mess of reporting this bug, which was nothing to do with the compiler. Thanks, Nick.
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 --- Comment #4 from NickParker at Eaton dot com 2011-09-04 21:27:43 UTC --- Hi, Thanks for your input and sorry to make a mess of reporting this. The arithmetic is fine and the code gives the results I expect. However, I have since discovered and corrected a 'bug'. I was not initialising my 'temporary result registers i.e. r2,r3,r4,r5,r6,r7. Regarding the arithmetic, the result is INTENTIONALLY accumulated from the lowest partial products to highest partial products so that at most only 3 additions are ever needed per partial product. Thanks, Nick
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 --- Comment #5 from NickParker at Eaton dot com 2011-09-04 21:29:40 UTC --- Thanks, also was able to add a few movws to save cycles. Nick.
[Bug target/50289] New: [avr]: call-prologues saveing/restoring global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50289
Bug #: 50289
Summary: [avr]: call-prologues saveing/restoring global
register variables
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr
void bar (long long, long long, void*);
register char x asm (7);
void foo (char a)
{
asm volatile (:::6);
bar (0, 0, a);
}
This small program, compiles with
avr-gcc-4.6.1 -mcall-prologues -S -Os -mmcu=atmega8
to
foo:
ldi r26,lo8(1)
ldi r27,hi8(1)
ldi r30,lo8(gs(1f))
ldi r31,hi8(gs(1f))
jmp __prologue_saves__+((18 - 13) * 2)
1:
This means that __prologue_saves__ from libgcc saves R7 (i.e. R6..R17 and Y)
even though R7 is a global register variable and must not saved/restored by
function prologue/epilogue.
The function to fix is avr.c:sequent_regs_live()
[Bug target/50289] [avr]: call-prologues saving/restoring global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50289 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-04 Target Milestone|--- |4.6.2 Ever Confirmed|0 |1
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-04 22:19:53 UTC --- You don't need R20: Simply use %D0 which is cleared, anyway. As %0 is early clobber, it's not an input and you can clear is at the beginning. You don't need to clear R4/R5 (similar R6/R7): Just rearrange multiplications and use (note R6 is (implicitely) 0 at that time) mul %A1,%C2 movw r4,r0 instead of mul %A1,%C2 add r4,r0 adc r5,r1 You don't need to move to answer by hand; just use %A0 instead of R5 etc. and you save moves and register footprint (notice that this interferes with previous hint because you change registers even/odd; it's up to you to work it out and find smartest way of your assembler). Finally, you could let the compiler allocate temporary registers for you, i.e. a 16-bit instead of R2/R3 etc. The compiler knows better which registers are best and will try to use call-clobbered registers instead of expensive call-used ones. All in all, you will get a much greater performance gain by tweaking you code than the compiler could ever do by saving some poor register moves ;-)
[Bug tree-optimization/50290] New: [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -flto -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290 Bug #: 50290 Summary: [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -flto -funroll-loops Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25190 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25190 reduced testcase Compiler output: $ gcc -O2 -flto -fno-tree-loop-optimize -fno-tree-vrp -funroll-loops testcase.c In file included from testcase.c:14:0, from :0: testcase.c: In function 'main': testcase.c:23:1: internal compiler error: in distribute_notes, at combine.c:13282 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Tested revisions: r178508 - crash r177543 - OK 4.6 r177922 - OK
[Bug rtl-optimization/50290] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -flto -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50290 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |rtl-optimization Target Milestone|--- |4.7.0
[Bug c++/49267] Ambiguity with conversion functions T and T, initializing a T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-04 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #6 from Michael Hope michael.hope at linaro dot org 2011-09-04 23:55:51 UTC --- Seen also when building perl with -marm: https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/838994 Exists in 4.6.1 and trunk r178025. Does not exist in 4.5.3.
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099
--- Comment #7 from Michael Hope michael.hope at linaro dot org 2011-09-05
00:05:23 UTC ---
arm_legitimate_index_p() seems to be wrong. Near the end it has:
/* For ARM v4 we may be doing a sign-extend operation during the
load. */
if (arm_arch4)
{
if (mode == HImode
|| mode == HFmode
|| (outer == SIGN_EXTEND mode == QImode))
range = 256;
else
range = 4096;
}
else
range = (mode == HImode || mode == HFmode) ? 4095 : 4096;
The final 4096 range is incorrect for ARM mode sign extends. The arm_arch4
path looks good.
[Bug c/50291] New: A bug of if-condition optimization in x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50291
Bug #: 50291
Summary: A bug of if-condition optimization in x32
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yahem...@gmail.com
Created attachment 25191
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25191
c example code
Hi,
I use the x32 compiler and encounter a optimization issue.
Attachments are the example code and the results.
Gcc compiler version : 4.7.0 20110817
OS and development environment : gcc version 4.5.2 under Mingw (32-bit), xp sp3
Command : x86_64-unknown-elf-gcc -mx32 -O2 example.c -S
In the example, if we don't comment the line of Fb(...) or Ff(...), we can find
out that compiler skip the result of if-condition in the example.c :
if( cca == 0 ccb == 0)
{
DataBlkPreAllocated = 1;
}
Because the cca and ccb may be changed by other function, this result is wrong.
If we add the –fno-if-conversion option, the compiler wouldn't skip this
if-condition.
But using –fno-if-conversion may generate more jump instructions in large
code.
So I guess this problem may be relative to the –fif-conversion optimization.
best regards,
[Bug c++/50282] pointer-to-member cast works incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282
--- Comment #6 from zhuli imzhuli at vip dot qq.com 2011-09-05 03:12:55 UTC
---
I guess we have some agreement on HOW gcc works. the following are what i got
through the test-cases:
1.simply using T4::f, will only get a value of T2::f, as the function f
accessed through T4,is actually defined in T2. NO CONVERSION WILL TAKE PLACE.
2.directly assign T4::f to an object of type void(T4::*)(void), will
IMPLICITELY cause an conversion from void(T2::*)(void) to void (T4::*)(void),
That means:
If I want to store a pointer-to-member-function, i should use its original
type, as T2::* ,or T4::T2::* which is only verbose but makes no difference in
current g++ implementation), in the case, and that's what i usually have to
have done in my programs (but not in the test-cases).
BUT:
1.This form is anti-literal. becaouse the programmer should always be aware of
where the function is implemented so as to store it in a generic way, or he
should use template.
2.To be more anti-literal, considering the following cases:
assume i implement a function T::f4, and f4 is originally a member-function
of T4, and i give two assignment:
void (T2::*pf2)() = T4::f ; // 1 OK, because f is implemented in T2
void (T2::*pf42)() = T4::f4 ; // 2 Error, because f4 is implemented in T4
as we both know how gcc works, and we know the second assignment voilabe the
c++ standard about No casting from D::f to B::f, so i say we feel no strange
about the result, but IT IS STILL CONFUSING, right ? event option -Wall will
not yield any warning or suggesting about the first line. At least I think such
a warning is much useful than a warning like unused variable.
So, I can accepte the way gcc implements the conversions, for I just tested
several cases and i can find out which way I can follow. But I have some
suggestions:
For the compiler always knows from the codes that f is accessable through T4,
we can have two forms of assign T4::f to objects of type T4::*,
1. (void)(T4::*pf4)() = T4::T2::f, or
2, (void)(T4::*pf4)() = static_castvoid (T4::*)()(T2::f) ;
and:
3 (void)(T4::*pf4)() = T2::f, will yield an warning.
I thinks this will make programmers feel easier and happier.
(In reply to comment #5)
The problem is is your code, not gcc
The type of T4::f is void(T2::*)() not void(T4::*)() so when you cast the
pointer to void(T4::*)() you are not casting back to the original type.
You can fix the code by using reinterpret_castvoid(T2::*)() for the cases
that use the expression T4::f, instead of reinterpret_castvoid(T4::*)()
For what it's worth, clang gives exactly the same result as g++ for a reduced
version of your program:
// define class N with no member,
// we just need a type void(N::*)() of which an object can hold a
pointer-to-member-function
class N {} ;
// define class T1 T3 with some member data/functions
// so that an object of class T4 which derives from T1 T2 T3
// will has its base object of type T2 have different address from the object
itself.
class T1
{
public:
char c ;
int i ;
} ;
class T3:virtual public T1
{
public:
int i3 ;
public:
virtual void f2() {
__builtin_printf(Foo3 !! this=%p\n, (void*)this);
} ;
} ;
// define class T2
// T2 has a memmber function f, which our pointer-to-member-function will
point
to.
// as T4 derives from T2 as a public base type, this function is an accessable
from T4 ;
// the function outputs the value of 'this' pointer, which i expect it always
points to an object of T2.
class T2
{
public:
int i2 ;
public:
virtual void f() {
__builtin_printf(Foo2 !! this=%p\n, (void*)this);
} ;
} ;
// define class T4, which simply derives from T1T2T3
class T4:public virtual T1, public T3, public T2
{} ;
int main(int, char**)
{
T4 t4 ;
void (N::*pfn)() = 0;
void(T4::*pf4)() = T4::f ;
// this line shows the address of t4 and its base object t4.t2 differ ;
__builtin_printf(AddressOf t4=%p, t4.t2=%p\n, (void*)(t4),
(void*)((T2)(t4)));
{
__builtin_printf(\nwhat i expect:\n);
// the following lines show what i expect to see:
// no matter what form the function call is, the function tells me the
address of t4.t2
t4.f() ;
(t4.*(T4::f))() ;
(t4.*pf4)() ;
}
{
__builtin_printf(\nTestCase1:\n);
__builtin_printf(pfn assignment: pfn =
reinterpret_castvoid(N::*)()(T4::f) \n);
__builtin_printf(Function call form:
(t4.*reinterpret_castvoid(T4::*)()(
pfn )() \n);
// Case1:
// pfn is assigned directly from T4::f,
// but actually, its value shows that is T2::f
pfn= reinterpret_castvoid(N::*)()(T4::f) ;
// comparing with the result i memtioned above, this is not what i want.
(t4.*reinterpret_castvoid(T4::*)()(pfn))() ;
}
{
__builtin_printf(\nTestCase2:\n);
__builtin_printf( pfn assignment: pfn =
reinterpret_castvoid(N::*)()(pf4) \n);
__builtin_printf(Function call
[Bug ada/50292] New: compiler bug box - pl-io.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50292 Bug #: 50292 Summary: compiler bug box - pl-io.ads Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: gary...@comcast.net
[Bug ada/50292] compiler bug box - pl-io.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50292 --- Comment #1 from Gary Barnes garynot at comcast dot net 2011-09-05 04:09:32 UTC --- Created attachment 25192 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25192 gnatchop file containing the source gnatchop format file with the source code causing the bug box. gcc \ -c \ -gnata \ -gnatE \ -fstack-check \ -gnatef \ -gnatf \ -gnatm50 \ -gnatn \ -gnato \ -gnatU \ -gnatwa \ -gnatwe \ -gnatwi \ -gnatwj \ -gnatwK \ -gnatwl \ -Wuninitialized \ -gnatVa \ -pass-exit-codes \ -O \ -g \ -gnatA \ ./pb_code_main.adb +===GNAT BUG DETECTED==+ | 4.5.1 20100924 (Red Hat 4.5.1-4) (i686-redhat-linux-gnu) Assert_Failure sem_ch3.adb:12928| | Error detected at pl-io.ads:510:9| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug ada/50292] compiler bug box - pl-io.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50292 --- Comment #2 from Gary Barnes garynot at comcast dot net 2011-09-05 04:10:32 UTC --- gcc \ -c \ -gnata \ -gnatE \ -fstack-check \ -gnatef \ -gnatf \ -gnatm50 \ -gnatn \ -gnato \ -gnatU \ -gnatwa \ -gnatwe \ -gnatwi \ -gnatwj \ -gnatwK \ -gnatwl \ -Wuninitialized \ -gnatVa \ -pass-exit-codes \ -O \ -g \ -gnatA \ ./pb_code_main.adb +===GNAT BUG DETECTED==+ | 4.5.1 20100924 (Red Hat 4.5.1-4) (i686-redhat-linux-gnu) Assert_Failure sem_ch3.adb:12928| | Error detected at pl-io.ads:510:9| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug c++/50248] [C++0x] unnecessary instantiation of constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50248 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-09-05 04:33:14 UTC --- Author: jason Date: Mon Sep 5 04:33:08 2011 New Revision: 178518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178518 Log: PR c++/50248 Core 1358 * init.c (perform_member_init): Don't diagnose missing inits here. (emit_mem_initializers): Or here. * method.c (process_subob_fn): Don't instantiate constexpr ctors. * semantics.c (cx_check_missing_mem_inits): New. (explain_invalid_constexpr_fn): Call it. (register_constexpr_fundef): Likewise. Leave DECL_DECLARED_CONSTEXPR_P set when the body is unsuitable. (cxx_eval_call_expression): Adjust diagnostics. (cxx_eval_constant_expression): Catch use of 'this' in a constructor. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-48089.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
[Bug c++/49458] [C++0x] Obvious candidate for conversion to function lvalue rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49458 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-09-05 04:33:54 UTC --- Author: jason Date: Mon Sep 5 04:33:48 2011 New Revision: 178520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178520 Log: PR c++/49267 PR c++/49458 DR 1328 * call.c (reference_binding): Set rvaluedness_matches_p properly for reference to function conversion ops. (compare_ics): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C trunk/gcc/testsuite/g++.dg/cpp0x/rv-func3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49267] Ambiguity with conversion functions T and T, initializing a T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-09-05 04:34:01 UTC --- Author: jason Date: Mon Sep 5 04:33:57 2011 New Revision: 178521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178521 Log: PR c++/49267 * call.c (reference_binding): Don't set is_lvalue for an rvalue reference rfrom. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/49267] Ambiguity with conversion functions T and T, initializing a T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49267 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-09-05 04:33:53 UTC --- Author: jason Date: Mon Sep 5 04:33:48 2011 New Revision: 178520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178520 Log: PR c++/49267 PR c++/49458 DR 1328 * call.c (reference_binding): Set rvaluedness_matches_p properly for reference to function conversion ops. (compare_ics): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-conv1.C trunk/gcc/testsuite/g++.dg/cpp0x/rv-func3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
