[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #10 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:10:26 UTC ---
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you it's easy, I'm sure)
Hi, wanna chime in here. It has no implication on my original PR (I'm not
taking a pointer to member), and has no implication on the example code Jason
quoted from the draft (so CWG983 was just noise -.-). Perhaps it's useful to
show more examples:
struct A {
int a;
};
struct B : A { };
struct C : A { };
struct D : B, C { };
struct E : D {
// valid, refers to one declaration
using D::a;
};
The above is valid in C++0x, and invalid in C++03. Certain uses of the alias
name E::a are valid, while others are invalid (those that check subobject
affinity)
decltype(E::a) x; // valid
int x = E().a; // invalid
See WMM's paper at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1543.pdf and the
usenet discussion at
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/4ae640b13b0bd334/
.
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
--- Comment #11 from Johannes Schaub schaub.johannes at googlemail dot com
2011-09-29 06:14:32 UTC ---
(In reply to comment #10)
(In reply to comment #9)
Excellent, then could you possibly comment on the implication for this PR?
(for
you it's easy, I'm sure)
...
Perhaps it's useful to show more examples:
struct A {
int a;
};
struct B : A { };
struct C : A { };
struct D : B, C { };
struct E : D {
// valid, refers to one declaration
using D::a;
};
Fail, I forgot I showed the same example above already :) Please forgive.
[Bug fortran/50514] gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-29 06:58:24 UTC --- About run time checking: I believe the bit size of k is known at compile time, and the overhead to check n against it is negligible as compared to computing ishft itself and maybe n. Of course when I am asking -fcheck I am prepared to slower execution, but it may well pay off, if I find a bug. I believe programmer (debugging) time is now costlier than hardware time.
[Bug c++/50563] New: Weird syntax acceptance rules for non-static data members initialized in place (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563
Bug #: 50563
Summary: Weird syntax acceptance rules for non-static data
members initialized in place (C++0x)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ethou...@gmail.com
In the latest version it's possible to initialize data in place.
According to the standard, non-static data members can be initialized with:
int a = 0;
or
int a {0};
and not with the constructor syntax:
int a (0);
However there are probably no strict rules how the list of variables can be
initialized. I state that it should be normally allowed. Actually gcc accepts
the following syntax:
int a {10}, b {20};
as well as:
int a, b = 20;
but this one:
int a = 10, b = 20;
ends up with the following error message:
error: expected ‘;’ before ‘,’ token
I'm not completely sure, but it should be just strict rule: either the list of
variables syntax is not allowed when the variables are also initialized (so int
a,b=20; should fail too), or the list of variables syntax should be supported
as usual.
[Bug c++/50563] Weird syntax acceptance rules for non-static data members initialized in place (C++0x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50563
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29
07:55:55 UTC ---
struct S1 {
int a{10}, b{20}; // OK
};
struct S2 {
int a, b = 20;// OK
};
struct S3 {
int a = 10, b = 20; // Error
};
CCing Jason
[Bug fortran/50564] New: [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 Bug #: 50564 Summary: [4.7 Regression] Front-end optimization - ICE with FORALL Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: aben...@caltech.edu, tkoe...@gcc.gnu.org Reported by Andrew Benson at http://gcc.gnu.org/ml/fortran/2011-09/msg00154.html With -ffrontend-optimize, gfortran ICEs with internal compiler error: in gfc_trans_forall_1, at fortran/trans-stmt.c:3796 Workaround: -fno-frontend-optimize Said to be a 4.7 regression. Test case: program test implicit none double precision, allocatable, dimension(:) :: timeSteps integer :: iTime double precision:: ratio forall(iTime=1:2) timeSteps(iTime)=ratio**(dble(iTime)-0.5d0)-ratio**(dble(iTime)-1.5d0) end forall end program test
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c/50565] New: [4.5/4.6/4.7 Regression] initializer element is not computable at load time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Bug #: 50565 Summary: [4.5/4.6/4.7 Regression] initializer element is not computable at load time Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 25379 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25379 preprocessed source [forwarded from http://bugs.debian.org/642144] this may be a duplicate of PR38354, compiles on 32bit targets, on 64bit targets it succeeds with 4.4, but fails with 4.5, 4.6 and trunk: $ gcc -c message.i message.i:154:2: error: initializer element is not computable at load time message.i:154:2: error: (near initialization for 'byte_order[1].offset')
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com 2011-09-29 08:34:45 UTC --- William, thanks for quick response! With -funroll-loops regression is still present. Do you want me to attach some dumps?
[Bug c++/41796] ambiguous subobject diagnostic given too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 09:23:36 UTC --- Ah, point taken about the irrelevance of the defect for this specific PR, sorry for bothering. Yesterday I didn't even try to reconstruct how the discussion had evolved.
[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end Target Milestone|--- |4.5.4
[Bug middle-end/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 Carlos Becker bsys.com.ar at gmail dot com changed: What|Removed |Added CC||bsys.com.ar at gmail dot ||com --- Comment #9 from Carlos Becker bsys.com.ar at gmail dot com 2011-09-29 10:31:15 UTC --- Hello, thanks for taking care of this 'bug'. I am currently working with ITK (www.itk.org) which doesn't compile with -std=c++0x in gcc 4.6.1 due to this error. Even though the proposed patch seems to be a proper solution, to me it seems to be that using -fpermissive just to come around this particular error is allowing other non-confirming code to compile as well, which may not be desired in many situations (for instance, assigning a const pointer to a non-const pointer would not be regarded as an error). In my case, I have modified the patch to throw a warning instead, but probably the best solution would be to add a sort of -fno-constexpr-initialization-check flag. I read that the previous GCC extension is deprecated now, but it is important to take into account that then it would be hard to use c++11 with older code, just because of details like this one. Thank you.
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 10:42:52 UTC --- Manuel, is this the same as PR39813? (the latter should get a better Summary)
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 10:45:40 UTC --- Never mind, I don't think it's the same, but 39813 is also pretty weird, why error.c sees the member template as a friend it's a mystery to me...
[Bug target/50566] New: [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 Bug #: 50566 Summary: [avr]: Add support for better logging similar to -mdeb Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: g...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Target: avr -mdeb lets avr-gcc print log information as a file is being compiled but it's hard to depict from the information - what function is just being compiled - what pass gcc is in - ... Forover, it would be nice to have a printf-like function to print formatted output together with trees, RTXes, register classes, rtx codes, etc.
[Bug c++/15218] [DR 421] rvalue.field is not an lvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15218 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 10:57:40 UTC --- All the snippets are rejected in mainline (would be 4.7), all but Comment 3 in 4.6.x too.
[Bug target/50566] [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-29 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug c++/32350] Very high compile times for template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32350 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 11:16:51 UTC --- The attachment doesn't compile anymore. I don't think it makes sense to keep this open... in case resubmit with current timings obtained from current compilers.
[Bug c++/34996] Base class of explicitly instantiated class doesn't get instantiated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 11:23:25 UTC --- Jason can you clarify this? I'm also personally very interested, because this behavior also weakens the explicit instantiation testing in the library: in many cases, if there is a bug in a base class, the test cannot reveal it!
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
--- Comment #3 from janus at gcc dot gnu.org 2011-09-29 11:23:52 UTC ---
Here is a better version which is regression-free:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 179338)
+++ gcc/fortran/resolve.c (working copy)
@@ -269,18 +269,21 @@
if (sym-attr.if_source != IFSRC_UNKNOWN)
resolve_formal_arglist (sym);
+ /* F08:C1279. */
+ if (gfc_pure (proc)
+ sym-attr.flavor == FL_PROCEDURE !gfc_pure (sym))
+ {
+ gfc_error (Dummy procedure '%s' of PURE procedure at %L must
+ also be PURE, sym-name, sym-declared_at);
+ continue;
+ }
+
if (sym-attr.subroutine || sym-attr.external || sym-attr.intrinsic)
{
- if (gfc_pure (proc) !gfc_pure (sym))
- {
- gfc_error (Dummy procedure '%s' of PURE procedure at %L must
-also be PURE, sym-name, sym-declared_at);
- continue;
- }
-
if (proc-attr.implicit_pure !gfc_pure(sym))
proc-attr.implicit_pure = 0;
Will commit as obvious.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29 11:49:09 UTC --- (In reply to comment #9) Even though the proposed patch seems to be a proper solution, to me it seems to be that using -fpermissive just to come around this particular error is allowing other non-confirming code to compile as well, which may not be desired in many situations (for instance, assigning a const pointer to a non-const pointer would not be regarded as an error). Yup. Some compilers allow every single backwards-compatibility feature to be controlled by a separate option. The cost of developing, testing and maintaining that is enormous. In my case, I have modified the patch to throw a warning instead, but probably the best solution would be to add a sort of -fno-constexpr-initialization-check flag. I read that the previous GCC extension is deprecated now, but it is important to take into account that then it would be hard to use c++11 with older code, just because of details like this one. That older code wasn't valid in C++03 either, and relied on an extension which was deprecated many years ago. That sounds like exactly the sort of situation -fpermissive is for. Rather than changing the effect on this extension, I'd prefer if -fpermissive was changed to reject some truly *ancient* features which haven't been supported without -fpermissive by any version of G++ since 3.0
[Bug target/50566] [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-29 11:52:04 UTC --- Author: gjl Date: Thu Sep 29 11:51:59 2011 New Revision: 179344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179344 Log: PR target/50566 * config.gcc (extra_objs): Add avr-log.o for $target in: avr-*-rtems*, avr-*-*. * config/avr/t-avr (avr-log.o): New rule to compile... * config/avr/avr-log.c: ...this new file. * config/avr/avr.opt (mlog=): New option. * config/avr/avr-protos.h (avr_edump, avr_fdump): New macros. (avr_log_set_caller_e, avr_log_set_caller_f): New prototypes. (avr_log_set_avr_log): New prototype. (avr_log_t): New typedef. (avr_log): New declaration. * config/avr/avr.c (avr_option_override): Call avr_log_set_avr_log. Added: trunk/gcc/config/avr/avr-log.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/t-avr
[Bug fortran/50553] statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553 --- Comment #3 from janus at gcc dot gnu.org 2011-09-29 11:57:40 UTC --- Author: janus Date: Thu Sep 29 11:57:35 2011 New Revision: 179345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179345 Log: 2011-09-29 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * resolve.c (resolve_formal_arglist): Fix pureness check for dummy functions. PR fortran/50553 * symbol.c (check_conflict): Forbid TARGET attribute for statement functions. 2011-09-29 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * gfortran.dg/pure_formal_proc_3.f90: New. PR fortran/50553 * gfortran.dg/stfunc_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pure_formal_proc_3.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 --- Comment #4 from janus at gcc dot gnu.org 2011-09-29 11:57:40 UTC --- Author: janus Date: Thu Sep 29 11:57:35 2011 New Revision: 179345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179345 Log: 2011-09-29 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * resolve.c (resolve_formal_arglist): Fix pureness check for dummy functions. PR fortran/50553 * symbol.c (check_conflict): Forbid TARGET attribute for statement functions. 2011-09-29 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * gfortran.dg/pure_formal_proc_3.f90: New. PR fortran/50553 * gfortran.dg/stfunc_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pure_formal_proc_3.f90 trunk/gcc/testsuite/gfortran.dg/stfunc_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50553] statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from janus at gcc dot gnu.org 2011-09-29 12:10:22 UTC --- Fixed with r179345. Closing.
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 --- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-29 12:13:17 UTC --- (In reply to comment #14) Never mind, I don't think it's the same, but 39813 is also pretty weird, why error.c sees the member template as a friend it's a mystery to me... Paolo, feel free to take the patch in comment #7 and updated as needed. However, I am not very happy with it because it uses %E and that means we reconstruct an expression, which sometimes leads to something that does not resemble the original source code at all. It would be neat to have a way to print the template arguments without using %E. Also, I am not sure what is the current output after Nathan improved the candidate diagnostics.
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 --- Comment #5 from janus at gcc dot gnu.org 2011-09-29 12:14:03 UTC --- Comment #0 is fixed with r179345. I noticed that in 'resolve_formal_arglist' there are two separate checks for procedure dummies in elemental procedures (for functions/subroutines). Those clearly could be unified.
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-09-29 12:16:46 UTC --- No, that's OK. I should be able to reproduce this on a pool machine. It may be difficult to come up with a good heuristic here given that reassociation doesn't have a good estimate of register pressure available. The fix solved a couple of other problem reports in addition to 49749, so we need to be careful about constraining it too much. All this is just to say I may not have something for you right away. :)
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 12:20:51 UTC --- Thanks. Now in mainline we say this: 40793.C: In function ‘void f()’: 40793.C:5:31: error: no matching function for call to ‘staticPrint()’ 40793.C:5:31: note: candidate is: 40793.C:2:6: note: templateclass T, T t void staticPrint() 40793.C:2:6: note: template argument deduction/substitution failed: 40793.C:5:31: error: ‘double’ is not a valid type for a template constant parameter In 4.6.x we don't produce the last note and error message. What do you think?
[Bug c++/34996] Base class of explicitly instantiated class doesn't get instantiated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29 12:25:00 UTC --- Derived1::X must be defined in every translation unit that needs it. An explicit instantiation is *required* to not instantiate members of base classes: [temp.explicit]/8 An explicit instantiation that names a class template specialization is also an explicit instantiation of the same kind (declaration or definition) of each of its members (not including members inherited from base classes) ...
[Bug c++/34996] Base class of explicitly instantiated class doesn't get instantiated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 12:28:12 UTC --- Ah, ok, thanks Jonathan for looking up that. Then, I guess we have to live with this behavior.
[Bug middle-end/50262] PTA doesn't disambiguate locally allocated heap objects from pointed to by arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50262 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29 12:35:32 UTC --- Not disambiguated because the HEAP tag of q escapes and thus the points-to set of q has vars_contains_global set, which then aliases with p which just has nonlocal set. We'd probably need a vars_contains_nonlocal and vars_contains_escaped to distinguish the flow-sensitivity of nonlocal vs. escaped also in the generated points-to info.
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29 12:44:16 UTC --- The problem is that with front-end optimization, the forall body is changed from: timeSteps(iTime)=ratio**(dble(iTime)-0.5d0)-ratio**(dble(iTime)-1.5d0) which is a simple assignment (EXEC_ASSIGN) to a block of the form block tmp = dble(iTime) timeSteps(iTime)=ratio**(tmp-0.5) - ratio**(tmp-1.5) end block or something similar (in any case it is an EXEC_BLOCK); however, gfc_trans_forall_1 only handles: EXEC_ASSIGN, EXEC_WHERE, EXEC_POINTER_ASSIGN, EXEC_FORALL and EXEC_ASSIGN_CALL. That matches F2008 (cf. below), though one could allow BLOCK internally. R756 forall-body-construct is forall-assignment-stmt or where-stmt or where-construct or forall-construct or forall-stmt R757 forall-assignment-stmt is assignment-stmt or pointer-assignment-stmt
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29 13:01:49 UTC --- Seemingly caused by the patch for PR 44649: 2010-07-08 Janus Weil ja...@gcc.gnu.org PR fortran/44649 * check.c (gfc_check_c_sizeof,gfc_check_storage_size): New functions. The problem seems to be the call: + if (verify_c_interop (arg-ts) != SUCCESS) The function checks: if (ts-type == BT_DERIVED ts-u.derived != NULL) return (ts-u.derived-ts.is_c_interop || ts-u.derived-attr.is_bind_c) ? SUCCESS : FAILURE; else if (ts-is_c_interop != 1) return FAILURE;
[Bug ada/49944] [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49944 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.4
[Bug bootstrap/50047] [4.7 Regression] Revision 177670 failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29 13:11:53 UTC --- Fixed.
[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -ftree-dump-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50045 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.4.7
[Bug target/50350] [4.6 Regression] ICE (segfault) in canonicalize_float_value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug target/50275] [4.6 regression] libgcc build failure on LM32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50275 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libgcj/50421] [4.7 Regression] GC Warning: Out of Memory! Returning NIL!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50421 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i686-apple-darwin10 Host||x86_64-linux Target Milestone|--- |4.7.0
[Bug c++/50437] [C++0x] [4.7 regression] ICE for trivial use of lambda in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50437 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29 13:17:46 UTC --- Argument. X shall be an interoperable data entity that is not an assumed-size array. It might be sufficient to test -- besides the obvious stuff (cf. SIZEOF) -- just for derived types that those are BIND(C). * * * By the way, I think one should reject proc-pointers for both SIZEOF and C_SIZEOF. For C_SIZEOF because they are not interoperable (only type(c_funptr) is) and for SIZEOF as the pointee size and not the pointer size is returned, which does not make sense for functions. (gfortran currently returns 1 byte.)
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug bootstrap/50354] [4.7 regression] sparc64-linux gcc generates assembly code that gas rejects, breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50354 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug libgcj/50057] [4.7 regression] SIGSEGV in natObject.cc:58
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50057 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50458] [4.6 Regression] ICE when using brace-initializer for new array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug libgomp/50386] [4.7 Regression] libgomp.h:87:5: error: unnamed struct/union that defines no instances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50386 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29 13:15:17 UTC --- Fixed.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.2 |--- --- Comment #8 from janus at gcc dot gnu.org 2011-09-29 13:25:47 UTC --- (In reply to comment #6) Seemingly caused by the patch for PR 44649: ... which is: http://gcc.gnu.org/viewcvs?view=revisionrevision=161977 This patch itself doesn't do anything wrong AFAICS, it rather seems to expose an underlying bug: Either we need to set the 'is_c_interop' flag correctly or loosen the checks in verify_c_interop.
[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -ftree-dump-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50045 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.7 |4.7.0
[Bug tree-optimization/50389] [4.7 Regression] ICE: in execute_todo, at passes.c:1730 with -O -freorder-blocks -ftracer and __builtin___memcpy_chk()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50389 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/48660] [4.5/4.6/4.7 Regression] ARM ICE in expand_expr_real_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.4
[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 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-29 13:47:12 UTC --- (In reply to comment #0) Peter, can you retest the failing lto-bootstrap building the go compiler under current gcc trunk? I believe honza's recent ipa-related fixes may have fixed this.
[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-09-29 14:15:30 UTC --- 2011-09-29 Bill Schmidt wschm...@linux.vnet.ibm.com * graphite-scop-detection.c (make_close_phi_nodes_unique): New forward declaration. (remove_duplicate_close_phi): Detect and repair creation of duplicate close-phis for a containing loop. Fixed in rev 179351 (trunk), 179352 (4_6-branch), 179353 (ibm-4_6-branch).
[Bug c++/46715] template constructor - Compiler Bus error under -O2/-Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46715 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 14:24:23 UTC --- Feedback not forthcoming.
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-29 14:35:14 UTC --- (In reply to comment #16) Thanks. Now in mainline we say this: 40793.C: In function ‘void f()’: 40793.C:5:31: error: no matching function for call to ‘staticPrint()’ 40793.C:5:31: note: candidate is: 40793.C:2:6: note: templateclass T, T t void staticPrint() 40793.C:2:6: note: template argument deduction/substitution failed: 40793.C:5:31: error: ‘double’ is not a valid type for a template constant parameter In 4.6.x we don't produce the last note and error message. What do you think? Well, I think it is even better than Clang now. The locations are a bit off, the first error should point to 5.1 and the last one to 5.13, but that was not the point of the original submitter and I am not volunteering to do the work, so if you are happy, close it as fixed.
[Bug target/43723] Some ARMs support unaligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43723 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 Known to fail|| --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-09-29 14:40:28 UTC --- Trunk should now be fixed with Julian's patch to trunk. Ramana This is what I see today with trunk. a: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldr r0, [r0, #0]@ unaligned bx lr
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 14:52:27 UTC --- Agreed. I think that about locations we have other PRs, and, arguably, the issues are well known. Fixed in 4.7.
[Bug rtl-optimization/50567] New: Reload pass generates sub-optimal spill code for registers in presence of a vec_concat insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567
Bug #: 50567
Summary: Reload pass generates sub-optimal spill code for
registers in presence of a vec_concat insn
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siddhesh.poyare...@gmail.com
Reduced program:
typedef long long __m128i __attribute__ ((__vector_size__ (16)));
__m128i process(char *mem1, char *mem2)
{
long long frag1, frag2;
frag2 = frag1 = *((long long *) mem1);
if (mem2 mem1)
frag2 = *((long long *) mem2);
return (__m128i){frag2, frag1};
}
Generates redundant spills during the reload pass. IRA does not spill anything:
process:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
cmpq%rsi, %rdi
movq%rax, %rdx
jae .L2
movq(%rsi), %rdx
.L2:
movq%rdx, -16(%rsp)== here onwards
movq-16(%rsp), %xmm1
pinsrq $1, %rax, %xmm1
movdqa %xmm1, %xmm0
ret
This seems to happen because the pinsrq instruction (the vec_concat
implementation for x86_64) takes an SSE register for in and out and due to
this, the reload pass generates the spill code to move %rdx to %xmm1 as well as
the move from %xmm1 to %xmm0.
Ideally, the code generated should look like this:
process:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
cmpq%rsi, %rdi
movq%rax, %rdx
jae .L2
movq(%rsi), %rdx
.L2:
movq%rdx, %xmm0
pinsrq $1, %rax, %xmm0
ret
[Bug rtl-optimization/50567] Reload pass generates sub-optimal spill code for registers in presence of a vec_concat insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29 15:11:55 UTC --- I think this is because we prefer to do GR-sse register moves throuhg memory. -mtune=core2 should avoid this I think.
[Bug rtl-optimization/50567] Reload pass generates sub-optimal spill code for registers in presence of a vec_concat insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567 --- Comment #2 from Siddhesh Poyarekar siddhesh.poyarekar at gmail dot com 2011-09-29 15:24:52 UTC --- Thanks, that eliminated the spill to stack. The extra xmm1 to xmm0 move still remains: process: .LFB0: .cfi_startproc movq(%rdi), %rax cmpq%rsi, %rdi movq%rax, %rdx jae .L2 movq(%rsi), %rdx .L2: movd%rdx, %xmm1 pinsrq $1, %rax, %xmm1 movdqa %xmm1, %xmm0 ret
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 15:26:30 UTC --- Doesn't seem to make much sense, but thanks, anyway.
[Bug rtl-optimization/50567] Reload pass generates sub-optimal spill code for registers in presence of a vec_concat insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50567 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-29 15:27:58 UTC --- Indeed. It's a generic tuning thing to not be slow for old Athlons.
[Bug c++/49949] wrong sign for product of complexdouble and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 15:27:56 UTC --- Maybe Honza has ideas about this...
[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 15:31:03 UTC --- It seems, the warning is emitted *before* the pragma is actually processed in diagnostic_classify_diagnostic...
Re: [Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot ||com Paolo, you appear to have removed gcc-bugs from the CC list of several bugs. I don't know how you did it - our Bugzilla is supposed to prevent accidental removal of gcc-bugs, all bugs in the gcc product should always have gcc-bugs in their CC lists - but please add it back to the bugs from which you removed it. -- Joseph S. Myers jos...@codesourcery.com
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-29 15:40:19 UTC --- On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot ||com Paolo, you appear to have removed gcc-bugs from the CC list of several bugs. I don't know how you did it - our Bugzilla is supposed to prevent accidental removal of gcc-bugs, all bugs in the gcc product should always have gcc-bugs in their CC lists - but please add it back to the bugs from which you removed it.
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 15:45:44 UTC --- Are you aware that *all* the new bugs do *not* have it? Please explain that, if we want me to restore those CC (which I assumed were just bogus/legacy stuff)
Re: [Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
Something is strange ... messages sent to bugs from which gcc-bugs was removed do in fact still go to gcc-bugs anyway. So maybe there is no real problem with messages not going to gcc-bugs - but an apparent removal of gcc-bugs should not appear in messages reporting a change that presumably didn't intend to remove gcc-bugs, that's noise. -- Joseph S. Myers jos...@codesourcery.com
[Bug lto/50568] New: [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 Bug #: 50568 Summary: [4.7 Regression] Massive LTO failures Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86, revision 179350 has massive LTO failures: FAIL: c-c++-common/guality/pr43141.c -O2 -flto (internal compiler error) FAIL: c-c++-common/guality/pr43141.c -O2 -flto (internal compiler error) FAIL: c-c++-common/guality/pr43141.c -O2 -flto (test for excess errors) FAIL: c-c++-common/guality/pr43141.c -O2 -flto (test for excess errors) FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/guality/pr43141.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-alias-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-add.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-add.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-div.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/torture/complex-sign-mixed-mul.c -O2 -flto
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-29 15:48:40 UTC --- Something is strange ... messages sent to bugs from which gcc-bugs was removed do in fact still go to gcc-bugs anyway. So maybe there is no real problem with messages not going to gcc-bugs - but an apparent removal of gcc-bugs should not appear in messages reporting a change that presumably didn't intend to remove gcc-bugs, that's noise.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-29 15:49:32 UTC --- (In reply to comment #8) This patch itself doesn't do anything wrong AFAICS, it rather seems to expose an underlying bug: Either we need to set the 'is_c_interop' flag correctly or loosen the checks in verify_c_interop. I think the latter. I think one can allow all intrinsic types. However, one needs to be careful with characters: kind=4 is not interoperable and, e.g., for dummies only len=1 is allowed (while via storage association, c_char_string is a valid argument for a character(len=1,kind=c_char) :: dummy(*)). Note, additionally, that setting attr.is_c_interop is kind of difficult for 0.0_c_int ...
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||andi-gcc at firstfloor dot ||org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 15:50:30 UTC --- It may only happen on Linux/ia32.
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 15:49:47 UTC --- (and as you can see, this PR now is missing the CC, and all the messages we are exchanging are sent to the gcc-bugs mailing list, no problem at all)
[Bug middle-end/50448] [4.3/4.5/4.6/4.7 Regression] Missed optimization accessing struct component with integer address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50448 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end Known to work||3.4.6 Summary|[avr] Missed optimization |[4.3/4.5/4.6/4.7 |accessing struct component |Regression] Missed |with integer address|optimization accessing ||struct component with ||integer address Known to fail||4.7.0 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-29 15:55:05 UTC --- As explained in http://gcc.gnu.org/ml/gcc/2011-09/msg00353.html this looks like a middle-end flaw during tree - RTL lowering in explow.c:memory_address_addr_space() where the target cannot do anything about. Changed component from TARGET to MIDDLE-END.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-29 15:58:26 UTC --- Looking...
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 15:59:54 UTC --- I got lto1: internal compiler error: resolution sub id not in object file^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 16:02:04 UTC --- It is caused by revision 179348: http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00967.html
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29
16:03:15 UTC ---
Manuel, do you have an opinion about this rather old issue? In the meanwhile,
the warning became an hard error, when it applies. Thus the original testcase
is just accepted, and this variant:
void f(...);
struct X {
X();
X(const X);
};
void g() {
X x;
f(x);
}
gives:
40202.C: In function ‘void g()’:
40202.C:10:8: error: cannot pass objects of non-trivially-copyable type ‘struct
X’ through ‘...’
ICC warns exactly at the same line, 10, and nothing else.
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29 16:16:48 UTC --- (In reply to comment #4) In the meanwhile, the warning became an hard error, when it applies. It went from undefined to conditionally-supported behaviour in C++11 ICC warns exactly at the same line, 10, and nothing else. Clang too.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #113 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-29 16:24:56 UTC --- Even with PR47247 solved, -fprofile-generate -flto build fails at libbrowsercomps.so.ltrans23.ltrans.o:libbrowsercomps.so.ltrans23.o:function _ZTV17gfxUnknownSurface.local.706.2371: error: undefined reference to '_ZN11gfxASurface13BeginPrintingERK9nsAStringS2_' -fprofile-generate -flto is stupid, since one can profile w/o LTO and get a lot faster build. (We also need 15GB for libxul link). Still it seems that we miss some optimization we ought not.
[Bug target/50566] [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-29 16:25:09 UTC --- Author: gjl Date: Thu Sep 29 16:24:57 2011 New Revision: 179359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179359 Log: PR target/50566 * config/avr/avr-log.c (avr_log_vadump): Use %b to print bool. * config/avr/avr.c (avr_rtx_costs_1): New static function, renamed from avr_rtx_costs. (avr_legitimate_address_p): Use avr_edump to print log information filtered by avr_log. (extra_constraint_Q): Ditto. (avr_legitimize_address): Ditto. (avr_rtx_costs): Ditto. Rewrite as wrapper for avr_rtx_costs_1. (final_prescan_insn): Use avr_log.rtx_costs as filter. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-log.c trunk/gcc/config/avr/avr.c
[Bug target/50566] [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-29 16:29:04 UTC --- Done.
[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831 --- Comment #12 from janus at gcc dot gnu.org 2011-09-29 16:41:13 UTC --- Here's a link to a c.l.f. thread where I asked about this: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ae6a44043a3b1a95
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #7 from Frédéric Buclin LpSolit at netscape dot net 2011-09-29 16:46:08 UTC --- Our code doesn't CC gcc-bugs@gcc.gnu.org by default. This is useless as it already gets bugmails for all bugs in the gcc product thanks to our Bugzilla extension (was so since we upgraded from 2.20 to 3.6.2). If there are some bugs with gcc-bugs@gcc.gnu.org in the CC list, then this comes from old hacks GCC Bugzilla 2.20 had before I did the upgrade. You don't have to worry about this as it has no effect on getting bugmails. Once we upgrade to Bugzilla 4.2 (this won't happen before several months as we didn't release 4.2rc1 yet), powerless users won't be allowed to unCC someone else. We enforced this in 4.2 for the exact same reason as described here, i.e. a user having fun removing another user account from the CC list. If this is critical for overseers, I can backport and apply the patch to GCC Bugzilla.
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-09-29 16:51:28 UTC --- Thanks for the explanation. I don't think you need to do anything since the mails still get through - but seeing the address removed from the CC list is certainly confusing.
[Bug c++/39813] [feature request] __PRETTY_FUNCTION__ addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29 16:53:28 UTC --- Arguably no more confusing than seeing it in the CC list on some bugs and not others
[Bug middle-end/50565] [4.5/4.6/4.7 Regression] initializer element is not computable at load time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-29 17:03:28 UTC --- Anyreason Why ((int)( ((void *)(nmsgbuf.payload.part.ball.pos[0])) - ((void *)(nmsgbuf)) )) is being used instead of offsetof ?
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 17:14:56 UTC --- Thanks Jon for the clarification about C++11. Thus, let's wait a bit more in case Manuel has further comments, otherwise, let's just close this.
[Bug c++/40202] warning about passing non-POD objects through �...� should include name and location of declaration being called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40202
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-29
17:26:57 UTC ---
To the OP, you've probably fixed it by now, but you must have a varargs
function with ... somewhere, or you wouldn't get the error. You could add a
conflicting declaration which would make the compiler tell you the location.
void f(...);
struct X {
X();
};
struct Unique;
Unique* f(...);
void g() {
X x;
f(x);
}
t.cc:8: error: new declaration 'Unique* f(...)'
t.cc:1: error: ambiguates old declaration 'void f(...)'
Now you know where your mystery f(...) came from.
[Bug c++/48867] Using the compilation flag -mfpmath=sse breaks Snes9x build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48867 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 17:31:46 UTC --- Closing.
[Bug c++/47987] ICE on legal code (when attempting to inline non-implicitly instantiated template member function)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47987 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Severity|critical|normal --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 17:35:35 UTC --- Confirmed Fixed in 4.6.x and mainline. Not a regression.
[Bug c++/44620] gcc -fvisibility-ms-compat crash when throwing const char*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44620 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||FIXED Known to fail|| --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-29 17:49:58 UTC --- Fixed in 4.6.x and mainline. Not a regression.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 17:56:25 UTC --- The problem is in Breakpoint 2, process_symtab (data=0xccc0, name=0x82041fe .gnu.lto_.symtab.f1d7150d3f9de9cb, offset=1325, length=56) at /export/gnu/import/git/gcc/lto-plugin/lto-plugin.c:813 813 secdata = xmalloc (length); (gdb) p s $1 = 0x820420e .f1d7150d3f9de9cb (gdb) p obj-out-id $2 = 4294967295 (gdb) p/x obj-out-id $3 = 0x (gdb) We got 32bit overflow with 64bit random seed.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-29 18:03:21 UTC --- I don't see the problem on a 64bit bootstrap-lto. I guess i must have written some 32bit unsafe code.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 18:11:50 UTC --- (In reply to comment #6) I don't see the problem on a 64bit bootstrap-lto. I guess i must have written some 32bit unsafe code. We can't use 64bit random seed when LTO expects 32bit value.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-09-29 18:16:03 UTC --- Created attachment 25380 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25380 A patch This patch works for me. But I don't think it is correct. We need a way to specify HOST_WIDE_INT for lto plugin.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2011-09-29 18:17:08 UTC --- Created attachment 25381 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25381 Use long long in lto-plugin Can you please test this patch? Thanks.
