[Bug target/63805] ICE: in extract_insn, at recog.c:2327 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63805 --- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com --- I have similar error in LTO/x86_64, but stack is slightly different. gcc-trunk r218991, binutils-trunk current g++ -flto -o xx [6 files]. I'll try to reduce testcase. TesterTest.cpp:422:1: internal compiler error: in extract_insn, at recog.c:2327 0xb230b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/dimhen/src/gcc_current/gcc/rtl-error.c:110 0xb23148 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/dimhen/src/gcc_current/gcc/rtl-error.c:118 0xad96f8 extract_insn(rtx_insn*) /home/dimhen/src/gcc_current/gcc/recog.c:2327 0xad97a7 extract_insn_cached(rtx_insn*) /home/dimhen/src/gcc_current/gcc/recog.c:2218 0x86f8c9 cleanup_subreg_operands(rtx_insn*) /home/dimhen/src/gcc_current/gcc/final.c:3124 0xad51b9 split_insn /home/dimhen/src/gcc_current/gcc/recog.c:2937 0xadd3ad split_all_insns() /home/dimhen/src/gcc_current/gcc/recog.c:2991 0xadd4c8 rest_of_handle_split_after_reload /home/dimhen/src/gcc_current/gcc/recog.c:3938 0xadd4c8 execute /home/dimhen/src/gcc_current/gcc/recog.c:3967 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: g++ returned 1 exit status compilation terminated. /usr/local/binutils_current/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- Please try this patch: diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am index ecab22c..7a274b3 100644 --- a/libcc1/Makefile.am +++ b/libcc1/Makefile.am @@ -17,7 +17,7 @@ ## http://www.gnu.org/licenses/. ACLOCAL_AMFLAGS = -I .. -I ../config -gcc_build_dir = ../$(host_subdir)/gcc +gcc_build_dir = ../gcc AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \ -I $(gcc_build_dir) -I$(srcdir)/../gcc \ -I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \ diff --git a/libcc1/Makefile.in b/libcc1/Makefile.in index ce752c0..1916134 100644 --- a/libcc1/Makefile.in +++ b/libcc1/Makefile.in @@ -245,7 +245,7 @@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ visibility = @visibility@ ACLOCAL_AMFLAGS = -I .. -I ../config -gcc_build_dir = ../$(host_subdir)/gcc +gcc_build_dir = ../gcc AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \ -I $(gcc_build_dir) -I$(srcdir)/../gcc \ -I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to Ian Harvey from comment #0) The following (from recent c.l.f discussion) this one: https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/lbaOSWKSmhQ compiles without error with trunk r215574, despite the actual argument not meeting the requirements for the argument of the KIND intrinsic (the argument must be a data entity). The exact wording in the F08 standard, section 13.7.89, is: Argument. X may be of any intrinsic type. It may be a scalar or an array. I guess it's important here to stress the distinction between a function result (which is a data entitiy, i.e. scalar or array) and the function itself (which isnt't). In case one wants to know the KIND of the function result, one can use KIND(f()) (which seems to work correctly with gfortran), and KIND(f) indeed should give an error. Test case: PRINT *, KIND(f) print *, KIND(f()) contains FUNCTION f() INTEGER(SELECTED_INT_KIND(4)) :: f END FUNCTION END Currently prints: 0 2 but should reject the first line.
[Bug c++/64359] [5 Regression] alias_template_specialization_p template_args_equal show up high in profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64359 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thank you. The only outlier left is push_to_top_level(). It sometimes gets in the 8-10% range during Chrome compilation.
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363 --- Comment #2 from janus at gcc dot gnu.org --- Also it seems that polymorphic arguments to KIND are currently not rejected: class(*), allocatable ::c PRINT *, KIND(c) END
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
Draft patch:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c(Revision 218990)
+++ gcc/fortran/check.c(Arbeitskopie)
@@ -2531,13 +2531,20 @@ gfc_check_kill_sub (gfc_expr *pid, gfc_expr *sig,
bool
gfc_check_kind (gfc_expr *x)
{
- if (x-ts.type == BT_DERIVED)
+ if (x-ts.type == BT_DERIVED || x-ts.type == BT_CLASS)
{
- gfc_error (%qs argument of %qs intrinsic at %L must be a
- non-derived type, gfc_current_intrinsic_arg[0]-name,
+ gfc_error (%qs argument of %qs intrinsic at %L must be of
+ intrinsic type, gfc_current_intrinsic_arg[0]-name,
gfc_current_intrinsic, x-where);
return false;
}
+ if (x-ts.type == BT_PROCEDURE)
+{
+ gfc_error (%qs argument of %qs intrinsic at %L must be a data entity,
+ gfc_current_intrinsic_arg[0]-name, gfc_current_intrinsic,
+ x-where);
+ return false;
+}
return true;
}
[Bug libstdc++/60271] [C++1y] std::max(initializer_listT) cannot use std::max_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-21 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/57060] std::this_thread::get_id() == std::thread::id::id() without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57060 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-21 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Another option would be to return a non-zero id when !__gthread_active_p() instead of calling pthread_self()
[Bug libstdc++/52389] Allocation/deallocation across DLL boundary in std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52389 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) Draft patch: ... regtests cleanly.
[Bug c++/64270] packed fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64270 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||a3at.mail at gmail dot com --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 64369 has been marked as a duplicate of this bug. ***
[Bug c++/64369] Wreturn-local-addr for const argument with packed attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64369 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- dup *** This bug has been marked as a duplicate of bug 64270 ***
[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64324 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Version|unknown |5.0 Ever confirmed|0 |1 Known to fail||4.8.4, 4.9.3, 5.0 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.6.4 (deferred length was not implemented in 4.5) up to trunk (5.0). If I replace 'CHARACTER(:)' with 'CHARACTER(*)', I get two errors: FUNCTION tostring(arg) 1 Error: Character-valued module procedure 'tostring' at (1) must not be assumed length pr64324_db.f90:7:2: Error: User operator procedure 'tostring' at (1) cannot be assumed character length
[Bug libstdc++/52389] Allocation/deallocation across DLL boundary in std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52389 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- I suppose we could add a function to delete the name so it's done in the library with the matching deallocation function.
[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- As previously discussed, the --enable-libstdcxx-time function alters the experimental C++11 ABI and is not expected to be stable. It shouldn't be used (or necessary) going forward anyway.
[Bug libstdc++/59325] Provide a way to disable deprecated warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -78,11 +78,13 @@ # define _GLIBCXX_USE_DEPRECATED 1 #endif +#ifndef _GLIBCXX_DEPRECATED #if defined(__DEPRECATED) (__cplusplus = 201103L) # define _GLIBCXX_DEPRECATED __attribute__ ((__deprecated__)) #else # define _GLIBCXX_DEPRECATED #endif +#endif // Macros for ABI tag attributes. #ifndef _GLIBCXX_ABI_TAG_CXX11 This would allow you to just define _GLIBCXX_DEPRECATED= unconditionally
[Bug fortran/59103] [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59103 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Isn't this PR related to the patch at https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html?
[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54756 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Patch at https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html.
[Bug fortran/55591] strict-aliasing Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- what about applying this to stage 1 4.9 ? Too late for 5.0? Note that the patch in comment 3 may have to be updated to take into account the recent option reform (I did not test it).
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #91 from Oleg Endo olegendo at gcc dot gnu.org ---
Re: [RFC PATCH 9/9] [SH] Split QI/HImode load/store via r0
(In reply to Kazumoto Kojima from comment #83)
Created attachment 33992 [details]
a patch for the issue c#77
Interestingly, this reduces the total text size of CSiBE test ~0.04%
at -O2 even for the trunk i.e. with the old reload.
I've checked this change to prepare_move_operands without LRA with trunk
r218988, to see whether it should be enabled for non-LRA.
I can confirm the -1140 bytes / -0.04% on the CSiBE set. However, as mentioned
in comment #82, it results in unnecessary zero extensions before other
logic/arithmetic because combine doesn't (want to) see through the R0 hardreg.
Unnecessary sign/zero extensions are actually a separate topic (e.g. PR 53987).
If there was a good sign/zero extension elimination in place, this wouldn't be
an issue here.
I've tried disabling the prepare_move_operands change and instead adding the
following splitters, which are done after combine and before RA:
(define_split
[(set (match_operand:SI 0 arith_reg_dest)
(sign_extend:SI (match_operand:QIHI 1 displacement_mem_operand)))]
TARGET_SH1 can_create_pseudo_p ()
!refers_to_regno_p (R0_REG, R0_REG + 1, operands[1], NULL)
[(set (match_dup 2) (reg:SI R0_REG))
(set (reg:SI R0_REG) (sign_extend:SI (match_dup 1)))
(set (match_dup 0) (reg:SI R0_REG))
(set (reg:SI R0_REG) (match_dup 2))]
{
operands[2] = gen_reg_rtx (SImode);
})
(define_split
[(set (match_operand:QIHI 0 arith_reg_dest)
(match_operand:QIHI 1 displacement_mem_operand))]
TARGET_SH1 can_create_pseudo_p ()
!refers_to_regno_p (R0_REG, R0_REG + 1, operands[1], NULL)
[(set (match_dup 2) (reg:SI R0_REG))
(set (reg:QIHI R0_REG) (match_dup 1))
(set (match_dup 0) (reg:QIHI R0_REG))
(set (reg:SI R0_REG) (match_dup 2))]
{
operands[2] = gen_reg_rtx (SImode);
})
With these two splitters for mem loads I get exactly the same -1140 bytes /
-0.04% on the CSiBE set.
The simple test case
int test_tst (unsigned char* x, int y, int z)
{
return x[4] ? y : z;
}
does not contain the extu.b insn anymore, but instead we get this:
mov.b@(4,r4),r0
movr0,r1
tstr1,r1 should be: tst r0,r0
bf.L4
movr6,r5
.L4:
rts
movr5,r0
Other cases of new unnessecary zero-extension insns are in e.g. in
jpeg-6b/jdcoefct.s.
In linux-2.4.23-pre3-testplatform/arch/testplatform/kernel/signal.s some mov
reg,reg insns end up as:
extu.br0,r0
mov.br0,@(1,r8)
movr9,r0
shlr16r0
extu.br0,r0
mov.br0,@(2,r8)
movr9,r0
shlr16r0
shlr8r0
mov.br0,@(3,r8)
extu.br1,r0
mov.br0,@(4,r8)
movr1,r0
those can be wallpapered with peepholes though.
I've also tried using the splitters instead of the prepare_move_operands hunk
with LRA. But then I get spill errors on QI/HImode stores with displacement
addressing.
I've also tried removing the prepare_move_operands hunk with LRA. Compared
with trunk no-lra I get:
sum: 3368431 - 3378515+10084 / +0.299368 %
And LRA + prepare_move_operands hunk vs. trunk no-lra is:
sum: 3368431 - 3376507+8076 / +0.239756 %
Doing this kind of pre-RA R0 pre-allocation seems to result in better RA
choices w.r.t. commutative insns such as addition.
After all, maybe it's worth trying out an SH specific R0 pre-alloc pass that
offloads some of the RA choices. Of course it will not be able to solve issues
that arise when spilling code is generated that uses QI/HImode mem accesses
during the RA/spilling process.
R0 is the most difficult candidate, but I've also seen reports about FPU code
ICEing due FR0 spill failures when there are lots of (interdependent?) FMAC
insns at -O3 (e.g. FP matrix multiplication). Another register (class), of
which there is only one on SH, would be the MACH/MACL pair. Currently
MACH/MACL are fixed hardregs. Early experiments to allow MACH/MACL to be used
by RA and adding the MAC insn showed some problems (see PR 53949 #c3).
[Bug fortran/54878] libgfortran issues found by the Coverity scanner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54878 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- At least (d) and (f) are gone while others are still there at r218995.
[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61142 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- While working on adding some patterns for PR 64345, the issue got even worse. The problem in the description is just the tip of the iceberg. For the time being a bunch of peephole patterns can be used to limit the damage. The peepholes that I've added also seem to improve code when LRA is used.
[Bug target/64036] [SH] Evaluate re-enabling scheduling before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- In PR 22553 c#23 Kaz posted some CSiBE numbers to compare sched1 and no-sched1: CSiBE with -O2) test namesched1 no-sched1 sched1/no-sched1 bzip2-1.0.2 bzip2.d11.06 10.8067 1.02344 bzip2-1.0.2 bzip2recover4.54333 4.66333 0.974267 bzip2-1.0.2 bzip2.c42.8567 44.2067 0.969462 compiler vam.fib2.00333 1.97 1.01692 compiler vam.fact1.87333 1.88333 0.99469 compiler vam.test20.246667 0.25 0.986667 flex-2.5.31 flex13.1133 13.25 0.989686 jikespg-1.3 src/jikespg1.62 1.59333 1.01674 jpeg-6b jpegtran24.62667 4.74667 0.974719 jpeg-6b djpeg22.19333 2.28667 0.960641 jpeg-6b djpeg12.2 2.26667 0.970588 jpeg-6b cjpeg23.19333 3.05333 1.04585 jpeg-6b djpeg00.33 0.33 1 jpeg-6b cjpeg00.496667 0.496667 1 jpeg-6b cjpeg13.18 3.11667 1.02032 jpeg-6b jpegtran00.256667 0.256667 1 jpeg-6b jpegtran11.98667 2.00667 0.990033 libpng-1.2.5 png2pnm00.97 0.97 1.00344 libpng-1.2.5 pnm2png144.63 44.6933 0.998583 libpng-1.2.5 pnm2png07.94667 7.95 0.999581 libpng-1.2.5 png2pnm16.71667 6.71 1.00099 teem-1.6.0-src src/hex/dehex01.66 1.68 0.988095 teem-1.6.0-src src/hex/dehex110.8967 10.92 0.997863 teem-1.6.0-src src/hex/enhex140.5033 41.2133 0.982773 teem-1.6.0-src src/hex/enhex06.76333 6.86667 0.984951 zlib-1.1.4 minigzip044.73 45.0633 0.992603 zlib-1.1.4 minigzip5.41333 5.41333 1 (not CSiBE test with -O3. 201 frames decoded) mpeg2dec-0.3.12.18 2.22 0.981981
[Bug fortran/59103] [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59103 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) Interpretation request F08/0033, ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1875.txt, added additional restrictions to PURE as polymorphic variables might have IMPURE FINAL subroutines. Thus: * An INTENT(OUT) argument of a pure procedure should not be allowed to be polymorphic Note: This part is already covered by PR 54756 (see also the link to the patch in comment #2).
[Bug fortran/59103] [OOP] Reject deallocate/intent(out) for polymorphic var in PURE procedures (IR F08/0033)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59103 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) Isn't this PR related to the patch at https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html? Yes, but the patch does not cover all cases mentioned in comment 0.
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The patch in comment 2 needs to be update to
--- ../_clean/gcc/fortran/primary.c2014-12-16 22:27:14.0 +0100
+++ gcc/fortran/primary.c2014-12-21 14:50:53.0 +0100
@@ -2367,6 +2367,13 @@ build_actual_constructor (gfc_structure_
return false;
value = gfc_copy_expr (comp-initializer);
}
+ else if (comp-attr.allocatable)
+{
+ if (!gfc_notify_std (GFC_STD_F2008, No initializer for
+ allocatable component '%s' given in the structure
+ constructor at %C, comp-name))
+return false;
+}
else if (!comp-attr.deferred_parameter)
{
gfc_error (No initializer for component %qs given in the
Note that while
program testerprog
use testmod
Type(A) :: Me
allocate(Me%y)
Me = A(X=1, y=2)
print *, Me%y
end program
gives
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
program testerprog
use testmod
Type(A) :: Me
Me = A(X=1, y=2)
print *, Me%x, Me%y
end program
gives
1 2
i.e., 'allocate(Me%y)' conflicts with Me = A(X=1, y=2). May be this expected.
[Bug target/64036] [SH] Evaluate re-enabling scheduling before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
An example function, compiling with -O2 -m4:
int test_0 (unsigned short* x, int y, int z)
{
return
(x[0] + x[1] + x[2] + x[3] + x[4] + x[5] + x[6]
+ x[7] + x[8] + x[9] + x[10]) ? y : z;
}
Without sched1, there are lots of dependencies on the results of memory loads.
With sched1, there is generally more code generated and variable live ranges
are longer. The above function will use r8 and r9, which is not really
necessary. Memory load dependencies are reduced and more LS/EX/MT instructions
can be executed in parallel. Code size for the test function increases from
~37 insns to ~50 insns. Approximated cycles on SH4 pipeline should be ~37
cycles without sched1 and ~33 cycles with sched1. On SH4A the latency of a
load is 1 cycle, so without sched1 it should be ~28 cycles.
So basically this seems to stuff stall cycles with additional (reg-reg move)
instructions, but the end result is almost the same. The larger code size and
longer live ranges seem to eliminate the benefits. Using post-inc addressing
and appropriate scheduling and RA, it should be possible to get ~27 cycles (38
insns) on SH4 for that function.
If we could get that 37 - 27 cycle drop with sched1, it'd be worth enabling
it. It looks like addressing mode selection has to be improved first to reduce
pressure on R0. Even then, there should be some way to prevent sched1 if the
resulting code will only stuff stall cycles with reg-reg copy insns to avoid
code bloat, since larger code increases probability of icache misses.
[Bug fortran/47660] Retain warning text of -Wconversion messages when -Wconversion-extra is in effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r218995. Note that the warning i = 0._8 1 Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1) is no longer issued with 5.0.
[Bug fortran/53971] [OOP] Class container - reverse order of _vtab and _data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53971 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any progress?
[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64367 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sun Dec 21 15:16:08 2014 New Revision: 218997 URL: https://gcc.gnu.org/viewcvs?rev=218997root=gccview=rev Log: PR libstdc++/64367 * include/std/stdexcept: Don't use non-static member in sizeof. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/stdexcept
[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64367 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- should be fixed
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is there still some interest for this PR?
[Bug other/64370] New: [5 Regression] sreal.c:125:23: error: 'exp2' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64370 Bug ID: 64370 Summary: [5 Regression] sreal.c:125:23: error: 'exp2' was not declared in this scope Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o sreal.o -MT sreal.o -MMD -MP -MF ./.deps/sreal.TPo ../../gcc/gcc/sreal.c ../../gcc/gcc/sreal.c: In member function 'double sreal::to_double() const': ../../gcc/gcc/sreal.c:125:23: error: 'exp2' was not declared in this scope make[3]: *** [sreal.o] Error 1 Maybe fallback to pow?
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the purpose of this PR? To remind that submodules are not yet supported and/or that the commits for PR 52751 and PR 40973 will have to be updated when submodules will be supported? In the latter case could you elaborate?
[Bug libstdc++/63860] Ill-formed std::pair::swap implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63860 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org Version|4.8.3 |5.0 Target Milestone|--- |5.0 Known to fail||4.8.4, 4.9.3, 5.0 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Doesn't GCC 5 have the same problem?
[Bug tree-optimization/61931] Wrong Constant Folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61931 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- Created attachment 34307 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34307action=edit backport of r197965 (without neon bits) + testcase Patch which fixes this testcase; I'll do a full bootstrap and testsuite run with it next week.
[Bug c++/64371] New: 'stack smashing detected' in my code (NumStringConv).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64371 Bug ID: 64371 Summary: 'stack smashing detected' in my code (NumStringConv). Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: matszpk at interia dot pl I tried to run my program for conversion from numbers to strings (called as NumStringConv). Unhappilly, a testing program 'cstrtofXTest' causes 'stack smashing detected'. cstrtofXTest tests 'NumStringConv.cpp' code and that code causes (very likely) bug in GCC. Program has been compiled for i686 architecture under Gentoo Linux with gcc (Gentoo 4.9.2 p1.0, pie-0.6.1) 4.9.2 and glibc 2.20 with debuginfo. GCC has been configured with: Using built-in specs. COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.9.2/g++ Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.2/work/gcc-4.9.2/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.9.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.9.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.9.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.9.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include/g++-v4 --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.9.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2 p1.0, pie-0.6.1' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --with-cloog --disable-isl-version-check --enable-libsanitizer Thread model: posix gcc version 4.9.2 (Gentoo 4.9.2 p1.0, pie-0.6.1) Source codes for program available at https://github.com/matszpk/NumStringConv;. All compilations flags are in Makefile (I did not change content while compilation). There flags are: -Wall -std=gnu++11 -O2. Bug has been reproduced with flags '-Wall -std=gnu++11 -g' (without optimizations). Program was compiled without any warnings. I attach backtrace: *** stack smashing detected ***: ./cstrtofXTest terminated === Backtrace: = /lib/libc.so.6(+0x6da3a)[0xb7521a3a] /lib/libc.so.6(__fortify_fail+0x45)[0xb75b3415] /lib/libc.so.6(+0xff3ca)[0xb75b33ca] ./cstrtofXTest[0x8050df5] ./cstrtofXTest[0x80515e8] ./cstrtofXTest[0x804968e] /lib/libc.so.6(__libc_start_main+0xf2)[0xb74cbe12] ./cstrtofXTest[0x80499f9] === Memory map: 08048000-08061000 r-xp 08:01 765390 /home/mat/docs/src/NumStringConv-master/cstrtofXTest 08061000-08062000 r--p 00018000 08:01 765390 /home/mat/docs/src/NumStringConv-master/cstrtofXTest 08062000-08063000 rw-p 00019000 08:01 765390 /home/mat/docs/src/NumStringConv-master/cstrtofXTest 097ca000-097eb000 rw-p 00:00 0 [heap] b74b1000-b74b4000 rw-p 00:00 0 b74b4000-b764a000 r-xp 08:01 1912875/lib/libc-2.20.so b764a000-b764d000 r--p 00195000 08:01 1912875/lib/libc-2.20.so b764d000-b764f000 rw-p 00198000 08:01 1912875/lib/libc-2.20.so b764f000-b7651000 rw-p 00:00 0 b7651000-b766c000 r-xp 08:01 1534035 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcc_s.so.1 b766c000-b766d000 r--p 0001a000 08:01 1534035 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcc_s.so.1 b766d000-b766e000 rw-p 0001b000 08:01 1534035 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcc_s.so.1 b766e000-b76b2000 r-xp 08:01 1913171/lib/libm-2.20.so b76b2000-b76b3000 r--p 00043000 08:01 1913171/lib/libm-2.20.so b76b3000-b76b4000 rw-p 00044000 08:01 1913171/lib/libm-2.20.so b76b4000-b779b000 r-xp 08:01 1534281 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libstdc++.so.6.0.20 b779b000-b779f000 r--p 000e7000 08:01 1534281 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libstdc++.so.6.0.20 b779f000-b77a rw-p 000eb000 08:01 1534281 /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libstdc++.so.6.0.20 b77a-b77a7000 rw-p 00:00 0 b77b8000-b77ba000 rw-p 00:00 0 b77ba000-b77db000 r-xp 08:01 1913430/lib/ld-2.20.so b77db000-b77dc000 r--p 0002 08:01 1913430/lib/ld-2.20.so b77dc000-b77dd000 rw-p 00021000 08:01 1913430/lib/ld-2.20.so bfef4000-bff16000 rw-p 00:00 0 [stack] Przerwane (zrzut pamięci) Attachment in report is preprocessed file for analysis (for NumStringConv.cpp). Any response or solution will be appreciated. Sorry for my english.
[Bug c++/64371] 'stack smashing detected' in my code (NumStringConv).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64371 matszpk matszpk at interia dot pl changed: What|Removed |Added Target||i686-pc-linux-gnu Host||i686-pc-linux-gnu Build||i686-pc-linux-gnu Severity|normal |major --- Comment #1 from matszpk matszpk at interia dot pl --- I forgot about an important thing: cstrtofXTest tests a 'cstrtofXCStyle' function in NumStringConv.
[Bug target/53987] [SH] Unnecessary zero-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #4)
It seems that converting unsigned values to signed values, i.e. replacing
zero-extensions with sign-extensions and recombining sign-extensions with
loads could make sense in general.
For example, the following code from CSiBE
mpeg2dec-0.3.1/libmpeg2/motion_comp.s contains sequences like:
_MC_put_x_8_c:
.align 2
.L24:
mov.b @r5,r0
sett
extu.b r0,r1
mov.b @(1,r5),r0
extu.b r0,r0
addcr1,r0
sharr0
mov.b r0,@r4
sett
mov.b @(1,r5),r0
extu.b r0,r3
mov.b @(2,r5),r0
extu.b r0,r1
mov r3,r0
addcr1,r0
sharr0
mov.b r0,@(1,r4)
Here effectively only 8 bit values are calculated. The zero-extensions can
be omitted, since the higher bits do not influence the result of the lowest
8 bits and the higher bits are discarded after the 8 bit stores.
Sorry, bad example. The zero-extensions can't be emitted in this case because
of the right shift. In the following example bits 15 are don't care
void test_0 (unsigned short* x, int y, int z)
{
x[11] = ((x[0] + x[1] + 1) 1) + ((x[2] + x[3] + 1) 2) - y;
}
.. and there are no zero-extensions in this case. Using function arguments
instead:
void test_1 (unsigned short* x,
unsigned short a, unsigned short b, unsigned short c,
unsigned short d, unsigned short e)
{
x[11] = ((a + b + 1) 1) + ((c + d + 1) 2) - e;
}
... brings back the zero extensions. This is probably because of the SH ABI
(PR 52441), but in this case the extensions are really not needed.
[Bug rtl-optimization/64366] Segmentation fault in remove_pseudos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64366 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-21 Ever confirmed|0 |1 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- I get the same here when trying to compile the CSiBE set for -m4-single -O2 -mpretend-cmove and LRA enabled.
[Bug target/39423] [4.8/4.9/5 Regression] [SH] performance regression: lost mov @(disp,Rn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #39 from Oleg Endo olegendo at gcc dot gnu.org --- I'd like to close this PR since the immediate problem at hand has been fixed with a work-around.
[Bug jit/64296] link failure of libgccjit.so for in tree gmp/mpc/mpfr/isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64296 --- Comment #1 from Alfred Minarik alfred.minarik.1 at aon dot at --- just wanted to add, that I've found you can easily work around by make BOOT_CFLAGS='-fPIC -g -O2' (I don't know if something additionally gets compiled with -fPIC that needn't or shouldn't)
[Bug fortran/62298] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Apparently the ICE has been fixed between revisions r216305 (2014-10-16) and r216470 (2014-10-20), likely r216427 for pr63553. Note that the code is rejected with the patch at https://gcc.gnu.org/ml/fortran/2014-12/msg00098.html pr62298.f90:1151:46: pure subroutine string_assign_from_array( left, right ) 1 Error: INTENT(OUT) argument 'left' of pure procedure 'string_assign_from_array' at (1) may not be polymorphic pr62298.f90:1129:50: elemental subroutine string_assign_from_char( left, right ) 1 Error: INTENT(OUT) argument 'left' of pure procedure 'string_assign_from_char' at (1) may not be polymorphic
[Bug target/53513] [SH] Add support for fpchg insn and improve fenv support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #47 from Oleg Endo olegendo at gcc dot gnu.org --- Fixed/implemented for GCC 5.
[Bug target/59549] [SH] __builtin_return_address causes push/pop of PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59549 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- I haven't checked, but it could be related to this. When shifts are expanded/combined on SH2 (no dynamic shifts), library function calls might be intially inserted but then removed again during combine/split1. If that happens, PR push/pop insns might appear, although a function doesn't contain any function call.
[Bug fortran/62176] [OOP] Inconsistent resolution of GENERIC interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62176 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- As shown by pr64138 and the links therein, disambiguation of procedures by argument position is tricky. This does not change the fact that the behavior should be the same for, e.g., 'lle' and '='. Also the following code module m_string implicit none type t_string character, dimension(:), allocatable :: buffer integer :: length = 0 integer :: size = 0 contains ! Interfaces for string types generic :: character = string_to_char procedure :: string_to_char ! Element comparison operators procedure :: string_less_equal_char procedure, pass(right1) :: char_less_equal_string generic :: operator(=) = string_less_equal_char, char_less_equal_string ! Character compatibility interfaces generic :: lle = string_less_equal_char, char_less_equal_string end type t_string contains ! Return the string as character pure function string_to_char( this ) result(res) class(t_string), intent(in) :: this character(len=this%size) :: res if( allocated(this%buffer) ) then res = transfer( this%buffer(:this%size), res ) else res = '' end if end function string_to_char ! Comparison operator 'string = character' elemental function string_less_equal_char( left, right ) result(res) class(t_string), intent(in) :: left character(len=*), intent(in) :: right logical :: res res = ( left%character() = right ) end function string_less_equal_char ! Comparison operator 'character = string' elemental function char_less_equal_string( left1, right1 ) result(res) character(len=*), intent(in) :: left1 class(t_string), intent(in) :: right1 logical :: res res = ( left1 = right1%character() ) end function char_less_equal_string end module m_string still gives Error: 'string_less_equal_char' and 'char_less_equal_string' for GENERIC 'lle' at (1) are ambiguous
[Bug c++/64372] New: Spurious warning with throw in ternary operator returning const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
Bug ID: 64372
Summary: Spurious warning with throw in ternary operator
returning const reference
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tavianator at gmail dot com
The following program produces a spurious warning:
$ cat ternary-warning.cpp
const char
foo(const char* ptr)
{
return ptr ? *ptr : throw ptr;
}
$ g++ -Wall -c ternary-warning.cpp
ternary-warning.cpp: In function ‘const char foo(const char*)’:
ternary-warning.cpp:4:29: warning: returning reference to temporary
[-Wreturn-local-addr]
return ptr ? *ptr : throw ptr;
^
[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 34308 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34308action=edit hppa ivopts dump
[Bug target/64008] [SH] sh4-linux configured compiler rejects -m4-nofpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64008 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Ah, ancient issue is ancient: Here it starts: https://gcc.gnu.org/ml/gcc/2003-07/msg01851.html Still, I think Segher has a point in comment #4. Why not just enable all the multilibs for any configuration? At least it would be a friendly default value. If users don't want that (space limitations?), they can still disable it with --disable-multilib.
[Bug c++/64371] 'stack smashing detected' in my code (NumStringConv).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64371 matszpk matszpk at interia dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from matszpk matszpk at interia dot pl --- I apologize for mistake. My code was wrong and GCC correctly added stack smashing detector :).
[Bug lto/64373] New: [5 regression] ICE with lto related to variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64373 Bug ID: 64373 Summary: [5 regression] ICE with lto related to variably modified type Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: uecker at eecs dot berkeley.edu Created attachment 34309 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34309action=edit minimized test case xgcc (GCC) 5.0.0 20141221 (experimental) test.c: In function ‘a’: test.c:8:8: warning: passing argument 2 of ‘b’ from incompatible pointer type [-Wincompatible-pointer-types] b(10, p + i); ^ test.c:2:13: note: expected ‘float (*)[(sizetype)(L)]’ but argument is of type ‘float *’ extern void b(int L, float (*data)[L]); ^ test.c:9:1: internal compiler error: Speicherzugriffsfehler } ^ 0xafb59f crash_signal ../../gcc_git/gcc/toplev.c:358 0x9e3327 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc_git/gcc/tree.h:2892 0x9e3327 tree_is_indexable ../../gcc_git/gcc/lto-streamer-out.c:153 0x9ece57 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1332 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef8c8 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:654 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9ef016 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:603 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9eea95 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:522 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9eea95 DFS::DFS_write_tree_body(output_block*, tree_node*, DFS::sccs*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:522 0x9ed1a0 DFS::DFS_write_tree(output_block*, DFS::sccs*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1357 0x9edc97 DFS::DFS(output_block*, tree_node*, bool, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:495 0x9ee6cd lto_output_tree(output_block*, tree_node*, bool, bool) ../../gcc_git/gcc/lto-streamer-out.c:1552
[Bug target/17280] -mrelax and -O cause .uses directives in assembler to refer to non-existent local labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17280 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Dec 21 22:36:33 2014 New Revision: 218998 URL: https://gcc.gnu.org/viewcvs?rev=218998root=gccview=rev Log: gcc/testsuite/ PR target/17280 * gcc.target/sh/torture/pr17280.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr17280.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/17280] -mrelax and -O cause .uses directives in assembler to refer to non-existent local labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17280 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||olegendo at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- Seems to be working on trunk r218998. Test case added, closed.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #17)
(In reply to thopre01 from comment #16)
Did we? All I can find is you and Andreas mentionning that it should work
because it will be sign extended to int when doing the bitwise AND with
0xFF00.
What did I miss?
Ah sorry ... me bad. I haven't tried increasing the 'level' with the
bswaphi expander pattern in place. Will do that later.
So I did. Increasing the limit to
limit += 2 + (int) ceil_log2 ...
works for me for the signed short case.
However, the following function from the CSiBE set:
void
_nrrdSwap32Endian(void *_data, size_t N) {
int *data, w, fix;
size_t I;
if (_data) {
data = (int *)_data;
for (I=0; IN; I++) {
w = data[I];
fix = (w 0x00FF);
fix = ((w 0xFF00) 0x08) | (fix 0x08);
fix = ((w 0x00FF) 0x10) | (fix 0x08);
fix = ((w 0xFF00) 0x18) | (fix 0x08);
data[I] = fix;
}
}
}
seems to require 'limit += 3 + (int) ...' for the bswap insn to be detected.
Then, this fine function (from the same set)
void
_nrrdSwap64Endian(void *_data, size_t N) {
airLLong *data, l, fix;
size_t I;
if (_data) {
data = (airLLong *)_data;
for (I=0; IN; I++) {
l = data[I];
fix = (l 0x00FF);
fix = ((l 0xFF00) 0x08) | (fix 0x08);
fix = ((l 0x00FF) 0x10) | (fix 0x08);
fix = ((l 0xFF00) 0x18) | (fix 0x08);
#if defined(_WIN32)
fix = ((l 0x00FFi64) 0x20) | (fix 0x08);
fix = ((l 0xFF00i64) 0x28) | (fix 0x08);
fix = ((l 0x00FFi64) 0x30) | (fix 0x08);
fix = ((l 0xFF00i64) 0x38) | (fix 0x08);
#else
fix = ((l 0x00FFLL) 0x20) | (fix 0x08);
fix = ((l 0xFF00LL) 0x28) | (fix 0x08);
fix = ((l 0x00FFLL) 0x30) | (fix 0x08);
fix = ((l 0xFF00LL) 0x38) | (fix 0x08);
#endif
data[I] = fix;
}
}
}
requires 'limit += 6 + (int) ...'
(luckily, there's no _nrrdSwap128Endian in the set)
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #92 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Dec 21 23:37:42 2014 New Revision: 218999 URL: https://gcc.gnu.org/viewcvs?rev=218999root=gccview=rev Log: gcc/ PR target/55212 * config/sh/sh.md (*addsi3_compact): Add parentheses around condition. Add comments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug c++/64372] Spurious warning with throw in ternary operator returning const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org,
||manu at gcc dot gnu.org
Known to fail||4.9.2, 5.0
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
I think *p creates a temporary that only lasts until the end of the function,
so the code is undefined. Probably even:
const char
foz(const char* p)
{
return *p;
}
is undefined. However, G++ and Clang currently handles this as returning p:
;; Function const char foz(const char*) (null)
;; enabled by -tree-original
return retval = (const char ) NON_LVALUE_EXPR p;
;; Function const char foo(const char*, const char*) (null)
;; enabled by -tree-original
return retval = (const char ) (p != 0B ? NON_LVALUE_EXPR p :
NON_LVALUE_EXPR q);
;; Function const char fzz(const char*) (null)
;; enabled by -tree-original
cleanup_point return retval = (const char ) TARGET_EXPR D.2338, p != 0B
? (char) *p : Unknown tree: throw_expr
cleanup_point TARGET_EXPR D.2335, __cxa_allocate_exception (8);, *(const
char * *) D.2335 = p;;, __cxa_throw (D.2335, (void *) _ZTIPKc, 0B); ;,
0;
Note that in the testcase that throws, the gimple indicates that the reference
is set to null even when not throwing, which leads to a segmentation fault.
const char fzz(const char*) (const char * p)
{
const charD.10 D.2348;
const charD.10 D.2338;
charD.10 iftmp.1D.2349;
voidD.45 * D.2335;
[test.cc:18:24] if (pD.2330 != 0B) goto D.2350; else goto D.2351;
D.2350:
[test.cc:18:24] iftmp.1D.2349 = [test.cc:18:24] *pD.2330;
goto D.2352;
D.2351:
[test.cc:18:24] # USE = anything
# CLB = anything
D.2335 = __cxa_allocate_exceptionD.2334 (8);
[test.cc:18:24] try
{
[test.cc:18:24] [test.cc:18:24] MEM[(const charD.10 * *)D.2335] =
pD.2330;
}
catch
{
[test.cc:18:24] # USE = anything
# CLB = anything
__cxa_free_exceptionD.2336 (D.2335);
}
[test.cc:18:24] # USE = anything
# CLB = anything
__cxa_throwD.2333 (D.2335, _ZTIPKcD.2337, 0B);
D.2352:
[test.cc:18:24] D.2338 = iftmp.1D.2349;
[test.cc:18:24] try
{
[test.cc:18:24] D.2348 = 0;
[test.cc:18:24] return D.2348;
}
finally
{
[test.cc:18:24] D.2338 = {CLOBBER};
}
}
[Bug c/61864] Feature Request, -Wcovered-switch-default to identify dead default branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager egall at gwmail dot gwu.edu --- this(In reply to Chengnian Sun from comment #0) Currently, GCC supports -Wswitch and -Wswitch-enum. It also supports -Wswitch-default, which seems to be the exact opposite of clang's -Wcovered-switch-default. Personally I think gcc's -Wswitch-default is the better one to listen to; having a default case is a good back-up even if it will never actually be reached. Here is a link to a post that explains it better than I could: http://programmers.stackexchange.com/a/242896/161051
[Bug c/37041] -Wc++-compat refinements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041
Eric Gallager egall at gwmail dot gwu.edu changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment #5 from Eric Gallager egall at gwmail dot gwu.edu ---
A few other refinements to -Wc++-compat that I would like to see:
1. Have it properly handle stuff like the following idiom commonly found in
header files:
#ifdef __cplusplus
extern C {
#endif
/* code that is C-only */
#ifdef __cplusplus
}
#endif /* __cplusplus */
I would expect -Wc++-compat to treat something like the above similarly to how
the following pragmas would work:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wc++-compat
/* code that -Wc++-compat should ignore */
#pragma GCC diagnostic pop
While the version with pragmas is shorter, the `extern C` stuff is often
needed for separate reasons, and as such, it would be nice to avoid the need to
do both...
2. Make -Wc++-compat an umbrella warning flag like -Wall or -Wextra.
Currently -Wc++-compat warns about many different things, and sometimes I would
like to just focus on one of those things. I can think of at least the
following sub-flags that could be split off from it:
** -Wc++-compat-pointer-conversion for the ones like warning: request for
implicit conversion from 'void *' to 'char *' not permitted in C++
** -Wc++-compat-keywords for the ones like warning: identifier 'class'
conflicts with C++ keyword
** -Wc++-compat-visibility for the ones like warning: enum constant defined
in struct or union is not visible in C++ (or likewise with struct or union
instead of enum constant)
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |NEW CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Dominique d'Humieres from comment #3) Is there still some interest for this PR? Yes, seems still nice.
[Bug fortran/55591] strict-aliasing Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Dominique d'Humieres from comment #6) what about applying this to stage 1 4.9 ? Too late for 5.0? Note that the patch in comment 3 may have to be updated to take into account the recent option reform (I did not test it). Yes, I looked a couple of months ago in the patch comment #3, and it didn't work, figuring out why this didn't work lead to the patches on errno etc. Something in the option mechanism was causing this to be overwritten, I didn't figure out how to fix this cleanly. I would guess that, maybe, the new option handling mechanism makes this easier.
[Bug c++/64372] Spurious warning with throw in ternary operator returning const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #2 from Harald van Dijk harald at gigawatt dot nl ---
(In reply to Manuel López-Ibáñez from comment #1)
Probably even:
const char
foz(const char* p)
{
return *p;
}
is undefined.
No, that is fine. *p is an lvalue already, so no temporary gets created.
The original code was supposed to get a warning because ptr ? *ptr : throw ptr
was not an lvalue: for a ? b : c to be an lvalue, both b and c needed to be
lvalues.
However, the C++ standard has since changed, and if one operand is a
throw-expression, and the other is an lvalue, the result is now an lvalue. CWG
issue 1560:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1560
So in -std=c++11 mode, there should be no temporary, and no warning. (I haven't
checked if current versions of GCC already implement that, but I can find no
bug reports about it.)
[Bug c++/64372] Spurious warning with throw in ternary operator returning const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #3 from Harald van Dijk harald at gigawatt dot nl --- BTW, *(ptr ? ptr : throw ptr) would be fine, would not create any temporary, in any of the language standards.
[Bug c++/64372] Spurious warning with throw in ternary operator returning const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #4 from Tavian Barnes tavianator at gmail dot com --- I meant to include -std=c++11 in the OP, it still happens with that flag set. Good suggestion for the replacement though. The actual code was closer to i length ? a[i] : throw ... but I guess that can become (i length ? a : throw ...)[i].
