[Bug c++/57593] New: Friendship not extended into friend member-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593
Bug ID: 57593
Summary: Friendship not extended into friend member-declaration
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
The access granted by friendship extends into the member declarations of the
befriended class (11.3/2). Friend declarations are member-declarations but not
member declarations per se, so the standard is ambiguous. But GCC is
inconsistent.
class c {
class n {};
friend struct s;
};
struct s {
friend class c::n; // OK
friend c::n g(); // OK
friend void f() { c::n(); } // Error
};
All three should go the same way, if access is granted per declaration. If the
first two were invalid, private nested classes and related functions would be
impossible to befriend.
Rejection of the third case impedes use of a friend as part of a class
implementation, akin to members, such as the common case of operator . Clang
does accept it.
A defect report has been submitted.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 12 06:43:05 2013 New Revision: 199984 URL: http://gcc.gnu.org/viewcvs?rev=199984root=gccview=rev Log: PR target/56564 * varasm.c (decl_binds_to_current_def_p): Call binds_local_p target hook even for !TREE_PUBLIC decls. If no resolution info is available, return false for common and external decls. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c Author: jakub Date: Wed Jun 12 06:46:53 2013 New Revision: 199985 URL: http://gcc.gnu.org/viewcvs?rev=199985root=gccview=rev Log: PR target/56564 * gcc.target/i386/pr56564-1.c: Skip on darwin, mingw and cygwin. * gcc.target/i386/pr56564-3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr56564-1.c trunk/gcc/testsuite/gcc.target/i386/pr56564-3.c
[Bug tree-optimization/57592] [4.9 Regression] ICE in tree_unroll_loops_completely at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57592 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 CC||eraman at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE in |[4.9 Regression] ICE in |tree_unroll_loops_completel |tree_unroll_loops_completel |y at -O3|y at -O3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r199048.
[Bug tree-optimization/57537] [4.8/4.9 Regression] gcc.dg/vect/slp-widen-mult-half.c generating wrong code on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-12 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30298action=edit gcc49-pr57537.patch Untested fix.
[Bug rtl-optimization/57468] [4.9 Regression] 26% performance drop on important benchmark after r199298.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57468 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Thus fixed.
[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-06/msg00642.htm ||l Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug fortran/50548] gfortran -fcheck=all run time would be nice to detect different shapes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50548 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 199988.
[Bug fortran/51512] RFC: Bogus Return value of function/INTENT(OUT) was not set with allocatable results/dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51512 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at revision 199988. RFC: Should we really print a warning? The program is valid, though most of the time this indicates a programming error. IMO this is exactly what warnings are for. I suggest to close this PR as WONTFIX.
[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at revision 199988.
[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Jonathan Wakely from comment #1) Isn't this just http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition ? I don't think that this correct here (In C++11 the rules became relaxed). Just having a quick look at it, it looks like this depends on bug 53628.
[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the code in comment #0, I get the following ICE: In function 'do_something': Segmentation fault print *,this%abc_function() ^ Internal compiler error: Error reporting routines re-entered. gfcc: internal compiler error: Abort trap (program f951) or pr49630.f90: In function 'do_something': pr49630.f90:26:0: internal compiler error: in build_int_cst_wide, at tree.c:1213 print *,this%abc_function() ^ pr49630.f90:26:0: internal compiler error: Abort trap gfca: internal compiler error: Abort trap (program f951) for versions configured with --enable-checking=release. AFAICT the code in comment #1 compiles with 4.8 and trunk (it is not supported in 4.7).
[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Jonathan Wakely from comment #2) Although shouldn't it fail to compile, due to private destructor and copy constructor? I agree, it should fail. Interesting is, that the code compiles even when I use --no-elide-constructors.
[Bug c++/57594] New: [C++11] in-class static initializer can use deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57594
Bug ID: 57594
Summary: [C++11] in-class static initializer can use deleted
copy constructor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This should be rejected:
struct Private
{
Private(const Private) = delete;
Private() = default;
};
struct A
{
static constexpr Private p = Private();
};
[Bug c++/57595] New: [C++11] Destructor defaulted on first declaration is treated as public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57595
Bug ID: 57595
Summary: [C++11] Destructor defaulted on first declaration is
treated as public
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This should be rejected:
class Private
{
~Private() = default;
public:
Private() = default;
};
int main()
{
(void)Private{};
}
[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Daniel Krügler from comment #4) I don't think that this correct here (In C++11 the rules became relaxed). It was post-C++11, but as a DR we should implement it, and I see you're right, the initialization of int_ uses the lvalue-to-rvalue conversion immediately so it isn't odr-used. I've created PR 57594 and PR 57595 for the missing diagnostics.
[Bug c++/53628] [C++11][DR 712] Compiler requires definition of static member constants when not odr-used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 Ever confirmed|0 |1
[Bug c++/57595] [C++11] Destructor defaulted on first declaration is treated as public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57595 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- There possibly exists some overlap to bug 54812, doesn't it?
[Bug target/57578] SPE detection broken on Linux (bits/predefs.h: No such file or directory)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57578 --- Comment #2 from Roland Stigge stigge at antcom dot de --- OK, we have feedback now from Olivier Hainque: ... so looks correct to me. Thanks! So as soon as the change is checked in, we can close this bug. Thanks!
[Bug c++/54812] [C++11] Delete expression doesn't respect access of defaulted destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54812 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 57595 has been marked as a duplicate of this bug. ***
[Bug c++/57595] [C++11] Destructor defaulted on first declaration is treated as public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57595 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Thanks, I didn't find that *** This bug has been marked as a duplicate of bug 54812 ***
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se --- It's not too difficult to make the m68k backend use 32-bit offsets in its jump tables (adjust CASE_VECTOR_MODE, ASM_OUTPUT_ADDR_DIFF_ELT, ASM_RETURN_CASE_JUMP, drop the sign-extend from the tablejump expander, likewise in the unnamed insn that matches the output from the tablejump expander). I have a crude patch to do that, and make it compile-time selectable via an option. However, it seems to me that the compiler should be able to figure out for itself if a given jump table might need 32-bit offsets. In the worst case every element will overflow a (signed) 16-bit offset (0..32K-1 positive range) and need a GAS-inserted trampoline, for a total of 2 + 6 == 8 bytes per element. So tables with no more than 4K elements should work with 16-bit offsets. Tables larger than that may have their trampolines more than 32K away from the table PC base, which cannot work with 16-bit offsets, so for those the compiler should use 32-bit offsets. Seems to require implementing casesi for m68k though.
[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- It's broken since the Bugzilla update, unfortunately.
[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50293 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3
[Bug tree-optimization/57537] [4.8/4.9 Regression] gcc.dg/vect/slp-widen-mult-half.c generating wrong code on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jun 12 13:01:49 2013 New Revision: 20 URL: http://gcc.gnu.org/viewcvs?rev=20root=gccview=rev Log: PR tree-optimization/57537 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): If vect_handle_widen_op_by_const, convert oprnd1 to half_type1. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-patterns.c Author: jakub Date: Wed Jun 12 13:01:29 2013 New Revision: 19 URL: http://gcc.gnu.org/viewcvs?rev=19root=gccview=rev Log: PR tree-optimization/57537 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): If vect_handle_widen_op_by_const, convert oprnd1 to half_type1. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-patterns.c
[Bug tree-optimization/57537] [4.8/4.9 Regression] gcc.dg/vect/slp-widen-mult-half.c generating wrong code on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537 --- Comment #3 from Brooks Moses brooks at gcc dot gnu.org --- Thanks for the quick fix, Jakub! And congratulations on the auspicious commit number, as well. :)
[Bug fortran/57596] New: select type bug with optional variables?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 Bug ID: 57596 Summary: select type bug with optional variables? Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All The following code is producing a segfault with gcc version 4.9.0 20130612 (experimental) (GCC) Is that a bug? v MODULE base_types TYPE :: base_integer_type INTEGER :: i END TYPE base_integer_type TYPE :: base_character_type CHARACTER( 10 ) :: c END TYPE base_character_type END MODULE base_types PROGRAM main USE base_types IMPLICIT NONE INTEGER::i_val call get ( i_val=i_val ) write(*,*) 'i_val',i_val contains SUBROUTINE get (i_val, c_val) INTEGER, INTENT( OUT ), OPTIONAL :: i_val CHARACTER( : ), INTENT( OUT ), ALLOCATABLE, OPTIONAL :: c_val CLASS( * ), POINTER :: p TYPE( base_integer_type ),target :: i_base i_base%i=-12 p=i_base SELECT TYPE( p ) TYPE IS( base_integer_type ) IF(present(i_val)) i_val = p%i TYPE IS( base_character_type ) if(present(c_val)) c_val = p%c CLASS DEFAULT stop END SELECT END SUBROUTINE get END PROGRAM main ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x4120ED in _gfortrani_backtrace at backtrace.c:258 #1 0x401DD0 in _gfortrani_backtrace_handler at compile_options.c:129 #2 0x3FC8C35C1F #3 0x401C08 in get.1883 at main.f90:? #4 0x401B71 in MAIN__ at main.f90:? Segmentation fault (core dumped)
[Bug c++/38958] 'unused variable' warning emitted when extending the lifetime of a returned RAII type by holding a reference to const despite delayed destructor side-effects. [dtor]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug other/57597] New: ICE: in get_section, at varasm.c:312: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57597 Bug ID: 57597 Summary: ICE: in get_section, at varasm.c:312: Segmentation fault Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Host: i386-mingw32 Target: avr Build: i686-linux-gnu Created attachment 30299 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30299action=edit foo.c: C test case Compile the test case with avr-gcc -mmcu=atmega168 -S foo.c -fmerge-all-constants -O foo.c:12:1: internal compiler error: in get_section, at varasm.c:312 } ^ foo.c:12:1: internal compiler error: Segmentation fault This might be related to PR50739 == configure == Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 Thread model: single gcc version 4.8.0 20130306 (experimental) (GCC)
[Bug other/57597] ICE: in get_section, at varasm.c:312: Segmentation fault with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57597 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-12 CC||gjl at gcc dot gnu.org Summary|ICE: in get_section, at |ICE: in get_section, at |varasm.c:312: Segmentation |varasm.c:312: Segmentation |fault |fault with ||-fmerge-all-constants Ever confirmed|0 |1
[Bug c++/42021] Misleading error message when inherited typedefs cause ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42021 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug tree-optimization/56787] [4.8 Regression] Vectorization fails because of CLOBBER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56787 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #5 from Pat Haugen pthaugen at gcc dot gnu.org --- The new testcase fails on powerpc64-linux, as can be seen in http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00904.html.
[Bug target/55033] [4.7/4.8/4.9 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #8 from Pat Haugen pthaugen at gcc dot gnu.org --- The testcase added 6/7, gcc.target/powerpc/pr55033.c, fails on powerpc64-linux. spawn -ignore SIGHUP /home/pthaugen/work/build/gcc/trunk/gcc/xgcc -B/home/pthaugen/work/build/gcc/trunk/gcc/ /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/pr55033.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=8540 -msoft-float -msdata=eabi -G 8 -fno-common -S -m32 -o pr55033.s^M /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/pr55033.c:1:0: error: -msdata=eabi and -mcall-linux are incompatible^M compiler exited with status 1 output is: /home/pthaugen/src/gcc/trunk/gcc/gcc/testsuite/gcc.target/powerpc/pr55033.c:1:0: error: -msdata=eabi and -mcall-linux are incompatible^M FAIL: gcc.target/powerpc/pr55033.c (test for excess errors)
[Bug fortran/57598] New: [Coarray,caf] Add FPE-Summary printing (floating-point exception) for STOP/ERROR STOP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598 Bug ID: 57598 Summary: [Coarray,caf] Add FPE-Summary printing (floating-point exception) for STOP/ERROR STOP Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Fortran 2008 demands that the compiler prints a summary of the FPE at STOP/ERROR STOP. The patch at http://gcc.gnu.org/ml/fortran/2013-06/msg00077.html adds support for noncoarrays. One needs to do likewise for coarrays. However, as Bill pointed out at http://mailman.j3-fortran.org/pipermail/j3/2013-June/006458.html, printing on 32k images Note: On image n, the following floating-point exception are signalling: IEEE_DIVIDE_BY_ZERO is not a good idea. It's better to collect those statuses and print something like: Note: 1453 images terminated reporting a DIVIDE_BY_ZERO exception, ... For true multi-image support, one also needs to pass compile_options.fpe_summary to the CAF library and handle collecting all the flags (collective SUM reduction). Also STOP has to be handled, not only ERROR STOP as it is currently done. Note: Fortran 201x might change the handling, cf. thread at http://mailman.j3-fortran.org/pipermail/j3/2013-June/006452.html Simple patch for caf_single: --- a/libgfortran/caf/single.c +++ b/libgfortran/caf/single.c @@ -41,0 +42,3 @@ caf_static_t *caf_static_list = NULL; +/* Prototype of libgfortran's functions. */ +void _gfortran_caf_error_stop_str (const char *, int32_t); +void _gfortran_caf_error_stop (int32_t); @@ -176,6 +179 @@ _gfortran_caf_error_stop_str (const char *string, int32_t len) - fputs (ERROR STOP , stderr); - while (len--) -fputc (*(string++), stderr); - fputs (\n, stderr); - - exit (1); + _gfortran_error_stop_string (string, len); @@ -188,2 +186 @@ _gfortran_caf_error_stop (int32_t error) - fprintf (stderr, ERROR STOP %d\n, error); - exit (error); + _gfortran_error_stop_numeric_f08 (error);
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 Teresa Johnson tejohnson at google dot com changed: What|Removed |Added CC||ccoutant at google dot com, ||tejohnson at google dot com --- Comment #1 from Teresa Johnson tejohnson at google dot com --- Cary, any ideas on how to fix this issue? Thanks, Teresa
[Bug fortran/57596] select type bug with optional variables?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Close as INVALID - feel free to re-open if you disagree. Seems to be invalid. Fortran 2008 has in 8.1.3.3 Attributes of associate names: Within an ASSOCIATE or SELECT TYPE construct [...] If the selector has the OPTIONAL attribute, it shall be present.
[Bug target/57329] ICE with -O2 and -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329 --- Comment #3 from Martin Jansa Martin.Jansa at gmail dot com --- Hi Terry, With Bin's patch at http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00784.html, we will get correct rtx cost. I can confirm that with 4.8.1 + this patch I don't see ICE anymore. I believe this is the cause of the issue and am doing back port to 4.8 branch. Please do, thanks. I'll start one more build with 4.8.1 but without this patch to check that it wasn't fixed by some other change between 4.8.0 and 4.8.1 - but if I don't reply today, then it's really fixed by Bin's patch.
[Bug c++/57599] New: g++ accepts invalid dynamic_cast of a const type to a regular type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599
Bug ID: 57599
Summary: g++ accepts invalid dynamic_cast of a const type to a
regular type
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abel at gcc dot gnu.org
The following code is accepted by g++ (versions 3.3, 4.6, 4.7 at least, I
didn't check trunk) but seems to be invalid c++ and is rejected by clang 3.2,
icc 13, msvc 12:
class A {
};
class B : public A {
};
int main() {
A* a;
B* b = new B();
a = dynamic_castconst A*(b);
return 0;
}
An expected error is along the lines of (icc):
error: a value of type const A * cannot be assigned to an entity of type A
*
[Bug c++/57599] g++ accepts invalid dynamic_cast of a const type to a regular type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The summary is very misleading. You're not casting a const type to a non-const type, you're casting a non-const type to a const type, then assigning that to a non-const type. What actually happens is that dynamic_castconst A*(b) returns A*
[Bug c++/57599] g++ accepts invalid assignment of a dynamic_castconst A* to A*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Summary|g++ accepts invalid |g++ accepts invalid |dynamic_cast of a const |assignment of a |type to a regular type |dynamic_castconst A* to ||A* --- Comment #2 from Andrey Belevantsev abel at gcc dot gnu.org --- Sorry, I tried to fix the summary. Feel free to improve it more if needed :)
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- I'll take a look, but at first glance it looks like have_multiple_function_sections isn't being set in dwarf2out.c, which leads it to assume that it can use symbol - symbol expressions in the range lists. That flag is set by the switch_text_section hook, which is called from final_scan_insn when it sees a NOTE_INSN_SWITCH_TEXT_SECTIONS insn. When -freorder-blocks-and-partitions is turned on, is such a NOTE being emitted?
[Bug tree-optimization/57600] New: Turn 2 comparisons into 1 with the min
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
Bug ID: 57600
Summary: Turn 2 comparisons into 1 with the min
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
in this code:
double SumProduct(const double* v1, const double* v2, int n1, int n2)
{
double sum=0;
for(int i=0; in1 in2; ++i)
sum += v1[i]*v2[i];
return sum;
}
it seems clear that in1 in2 should be replaced with imin(n1,n2) with the
min computation taken out of the loop. Not only do we have 2 comparisons
instead of one in the loop, this also prevents vectorization.
The closest PRs I have found (PR 10520 and PR 21855) are actually very
different.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Mikael Pettersson from comment #3) It's not too difficult to make the m68k backend use 32-bit offsets in its jump tables (adjust CASE_VECTOR_MODE, ASM_OUTPUT_ADDR_DIFF_ELT, ASM_RETURN_CASE_JUMP, drop the sign-extend from the tablejump expander, likewise in the unnamed insn that matches the output from the tablejump expander). I have a crude patch to do that, Does your patch define CASE_VECTOR_SHORTEN_MODE? Otherwise that'll probably be one of the first review comments. and make it compile-time selectable via an option. FWIW, -mbigtable for sh. However, it seems to me that the compiler should be able to figure out for itself if a given jump table might need 32-bit offsets. The length insn attribute needs to be defined in order to take advantage of the existing machinery. It seems it currently isn't, for m68k.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org --- The assembler already handles jump targets that are too far away (via the BROKEN_DOT_WORD hack), this issue is about growing the table itself too large so that the overflow table is not reachable any more within 32K.
[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #9) It's broken since the Bugzilla update, unfortunately. No broken since updating the server to a new machine. Updating Bugzilla was not the issue but updating the subversion on the server was.
[Bug c++/38958] 'unused variable' warning emitted when extending the lifetime of a returned RAII type by holding a reference to const despite delayed destructor side-effects. [dtor]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com --- Right sorry, the problem is the new subversion not sending commit messages at all to Bugzilla.
[Bug rtl-optimization/57518] [4.8/4.9 Regression] Redundant insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518 --- Comment #1 from wmi at google dot com --- post a candidate patch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00748.html
[Bug target/57583] large switches with jump tables are horribly broken on m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #5) The assembler already handles jump targets that are too far away (via the BROKEN_DOT_WORD hack), this issue is about growing the table itself too large so that the overflow table is not reachable any more within 32K. There's no confusion here. While a less involved patch will suffice where just the table is too big, CASE_VECTOR_SHORTEN_MODE can detect and handle both issues. I think it will also allow for jump-tables closer to the 4K entries than the significantly lower limit you'll find workable with a less involved patch and relying on BROKEN_DOT_WORD.
[Bug c++/57599] result of dynamic_castcv T is just T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57599 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-12 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- On it.
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 --- Comment #3 from Teresa Johnson tejohnson at google dot com --- Yes, there is a NOTE_INSN_SWITCH_TEXT_SECTIONS note emitted for functions that are split. In the attached test case the symbol-symbol expression is being generated across the split boundary of main(), and I confirmed that the NOTE is there in between the hot/cold sections. Thanks, Teresa On Wed, Jun 12, 2013 at 10:08 AM, ccoutant at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added CC||ccoutant at gcc dot gnu.org --- Comment #2 from Cary Coutant ccoutant at gcc dot gnu.org --- I'll take a look, but at first glance it looks like have_multiple_function_sections isn't being set in dwarf2out.c, which leads it to assume that it can use symbol - symbol expressions in the range lists. That flag is set by the switch_text_section hook, which is called from final_scan_insn when it sees a NOTE_INSN_SWITCH_TEXT_SECTIONS insn. When -freorder-blocks-and-partitions is turned on, is such a NOTE being emitted? -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug.
