[Bug tree-optimization/35468] New: LHS of assignment can be folded to a constant causing ICE
The following testcase causes an ICE. It is simply gcc.dg/980502-1.c
invoked with a different set of options, in particular, -fno-tree-dce.
Also included is the output of the final ccp pass. Notice the (dead)
assignment '88 = 1'. It looks like 'line[8]' in an lvalue context was
incorrectly folded to an rvalue. I believe that the RTL phases choke on
this when DCE is not allowed to eliminate it. I produced the output
below using trunk, but the issue shows up in 4.0.3 and probably elsewhere.
--- Contents of file 980502-1.c ---
char *const f(void)
{
char *const line = /dev/ptyXX;
line[8] = 1;
return line;
}
--- Failing compilation command ---
../rel/bin/gcc -v -save-temps -c -O2 -fdump-tree-ccp -fno-tree-dce 980502-1.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --with-gmp=/home/maddox/GCCLIBS
--with-mpfr=/home/maddox/GCCLIBS --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/home/maddox/trunk/rel --disable-bootstrap --disable-libmudflap
--disable-libgomp --enable-checking=yes,types
Thread model: posix
gcc version 4.4.0 20080304 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-fdump-tree-ccp'
'-fno-tree-dce' '-mtune=generic'
/home/maddox/trunk/rel/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -E -quiet -v
980502-1.c -mtune=generic -fdump-tree-ccp -fno-tree-dce -O2 -fpch-preprocess -o
980502-1.i
ignoring nonexistent directory
/home/maddox/trunk/rel/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/home/maddox/trunk/rel/include
/home/maddox/trunk/rel/lib/gcc/i686-pc-linux-gnu/4.4.0/include
/home/maddox/trunk/rel/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-fdump-tree-ccp'
'-fno-tree-dce' '-mtune=generic'
/home/maddox/trunk/rel/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -fpreprocessed
980502-1.i -quiet -dumpbase 980502-1.c -mtune=generic -auxbase 980502-1 -O2
-version -fdump-tree-ccp -fno-tree-dce -o 980502-1.s
GNU C (GCC) version 4.4.0 20080304 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b487bd365f366d1cb315758fb9e38dc9
980502-1.c: In function 'f':
980502-1.c:7: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4936
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- Contents of dump file 980502-1.c.056t.ccp2 ---
;; Function f (f)
f ()
{
bb 2:
88 = 1;
return /dev/ptyXX[0];
}
--
Summary: LHS of assignment can be folded to a constant causing
ICE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maddox at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug other/35457] Error building GCC trunk on CELL SPU
--- Comment #1 from ubizjak at gmail dot com 2008-03-05 08:13 --- What happens if you build from a clean directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
[Bug testsuite/31341] testsuite pr31041.c fails conflicting with stdint.h
--- Comment #6 from victork at gcc dot gnu dot org 2008-03-05 08:08 --- Subject: Bug 31341 Author: victork Date: Wed Mar 5 08:08:11 2008 New Revision: 132892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132892 Log: 2008-03-05 Victor Kaplansky [EMAIL PROTECTED] PR 31341 * gcc.dg/vect/pr31041.c: Fix. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr31041.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug bootstrap/35465] [4.4 Regression] Bootstrap failure at rev. 132875
--- Comment #1 from ubizjak at gmail dot com 2008-03-05 08:06 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00263.html: 2008-03-04 Geoff Keating [EMAIL PROTECTED] * fold-const.c (tree_single_nonnegative_warnv_p): Fix mixed declaration and code. (tree_invalid_nonnegative_warnv_p): Likewise. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35465
[Bug ada/35464] warning: condition is always False not issued inside generics
--- Comment #1 from sam at gcc dot gnu dot org 2008-03-05 08:34 --- Confirmed on GCC 4.4.0 20080303. I think this warning is disabled on purpose on instances because you may end up with conditions being always true or false *in somes instances only*. And in these cases, you certainly do not want the warning to occur, as the code may be perfectly legit. Reinstating the warning in instances would require analyzing whether the current test depends, directly or indirectly, on generic formal parameters, and issuing the warning only when there are no dependencies. This would require quite a lot of work to do it properly. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.1.2 4.3.0 |4.1.2 4.3.0 4.4.0 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2008-03-05 08:34:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35464
[Bug ada/35464] warning: condition is always False not issued inside generics
--- Comment #2 from sam at gcc dot gnu dot org 2008-03-05 08:38 --- Also note that for the same reason, you will not get a warning from an inlined body. See sem_warn.adb (Warn_On_Known_Condition). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35464
[Bug fortran/35459] ICE segmentaion fault when compiling valid code, using gfortran.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-03-05 09:43 --- (Hey, a UCL colleague! Small world...) I'm closing this bug as FIXED in 4.2.0. If you have any trouble upgrading to the newest compiler versions, feel free to ask for help on the gfortran mailing-list: [EMAIL PROTECTED] -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35459
[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32-64
--- Comment #3 from ubizjak at gmail dot com 2008-03-05 10:14 ---
Confirmed with
--cut here--
unsigned long long a;
unsigned int b;
unsigned short c;
unsigned long long mul32()
{
return a * b;
}
unsigned long long mul16()
{
return a * c;
}
--cut here--
Setting milestone to 4.3.0
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.3.0
Known to work||4.1.2 4.2.3
Last reconfirmed|-00-00 00:00:00 |2008-03-05 10:14:59
date||
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug rtl-optimization/35281] [4.3 regression] multiply with 0 generated for 64*32-64
--- Comment #4 from ubizjak at gmail dot com 2008-03-05 10:16 --- Note, this is _NOT_ the same issue as PR rtl-optimization/34522. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #6 from loki at gcc dot gnu dot org 2008-03-05 10:16 --- Subject: Bug 33009 Author: loki Date: Wed Mar 5 10:15:45 2008 New Revision: 132893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132893 Log: 2008-03-05 Gabor Loki [EMAIL PROTECTED] PR gcc/33009 * rtl-factoring.c (clear_regs_live_in_seq): Fix backward steps. (split_block_and_df_analyze): New. Split basic block and rebuild dataflow. (block_label_after): Use SPLIT_BLOCK_AND_DF_ANALYZE instead of SPLIT_BLOCK. (split_pattern_seq): Likewise. (erase_matching_seqs): Likewise. (split_pattern_seq): Skip return insn in case of REG_NORETURN note. PR testsuite/33009 * gcc.c-torture/compile/pr11832.c: Check -frtl-abstract-sequences. * gcc.c-torture/compile/pr33009.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c Modified: trunk/gcc/ChangeLog trunk/gcc/rtl-factoring.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #7 from loki at gcc dot gnu dot org 2008-03-05 10:27 --- Fixed. -- loki at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32-64
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-05 10:27 --- With -O we even have movl$0, %edx movla, %ecx imull %edx, %ecx I wonder why we do not constant-propagate / simplify here? Note that with 4.2 and 4.1 mul16 is also bad. Setting milestone to 4.3.1, only mul32 is a regression. Steven, shouldn't rtl const-prop catch this? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||stevenb dot gcc at gmail dot ||com GCC build triplet|i386-apple-darwin9.2.0 | GCC host triplet|i386-apple-darwin9.2.0 | GCC target triplet|i386-apple-darwin9.2.0 |i?86-*-* Keywords||missed-optimization Priority|P3 |P2 Summary|[4.3 regression] multiply |[4.3/4.4 Regression] |with 0 generated for 64*32- |multiply with 0 generated |64 |for 64*32-64 Target Milestone|4.3.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32-64
--- Comment #6 from ubizjak at gmail dot com 2008-03-05 10:32 ---
4.2 figures out in cse1 pass that:
(insn 9 8 10 2 (parallel [
(set (reg:DI 60 [ b ])
(zero_extend:DI (mem/c/i:SI (symbol_ref:SI (b) var_decl
0xb7caf108 b) [3 b+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) 79 {zero_extendsidi2_32} (nil)
(nil))
...
(insn 11 10 12 2 (parallel [
(set (reg:SI 61)
(mult:SI (reg:SI 62 [ a ])
(subreg:SI (reg:DI 60 [ b ]) 4)))
(clobber (reg:CC 17 flags))
]) 182 {*mulsi3_1} (nil)
(nil))
can simply be substituted with:
(insn 11 9 12 2 (set (reg:SI 61)
(const_int 0 [0x0])) 34 {*movsi_1} (nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-05 10:32 --- Subject: Bug 35336 Author: rguenth Date: Wed Mar 5 10:32:07 2008 New Revision: 132894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132894 Log: 2008-03-05 Richard Guenther [EMAIL PROTECTED] PR c++/35336 * tree.def (BIT_FIELD_REF): Document that operands 1 and 2 should be constants. * tree-cfg.c (verify_expr): Verify it. * fold-const.c (fold_truthop): Remove code generating BIT_FIELD_REFs of structure bases. (fold_binary): Likewise. (fold_ternary): Position and size of BIT_FIELD_REFs are always host integers. (make_bit_field_ref): Remove. (optimize_bit_field_compare): Remove. (all_ones_mask_p): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-cfg.c trunk/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35336
[Bug c++/35469] New: [4.3/4.4 Regression] Rejects JArrayjboolean
Recent 4.3.0 breaks the build of pdftk again with pdftk.C:4936: error: Java method 'void com::lowagie::text::pdf::PdfReader::removeUnusedNode(com::lowagie::text::pdf::PdfObject*, JArraybool*)' has non-Java parameter type 'JArraybool*' where appearantly the frontend has substituted bool for jboolean and now rejects it on the basis that bool is not TYPE_FOR_JAVA. -- Summary: [4.3/4.4 Regression] Rejects JArrayjboolean Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35469
[Bug c++/35469] [4.3/4.4 Regression] Rejects JArrayjboolean
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-05 10:40 --- Created an attachment (id=15261) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15261action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35469
[Bug c++/35469] [4.3/4.4 Regression] Rejects JArrayjboolean
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-05 10:47 --- Works with 4.2.3 and 4.1.3. Worked with 4.3.0 somewhen in January. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.3 4.2.3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35469
[Bug fortran/35470] New: Valid pointer assigment code gives compilation errors
This code compiles fine on all other known f95 compilers but gives an error in gfortran (code compiled with __GFORTRAN__ works, alternative does not): type real_pointer real, dimension(:), pointer :: p end type real_pointer ... recursive subroutine QuickSortArr_Real(Arr, Lin, R, index) !Sorts an array of pointers to arrays of reals by the value of the index'th entry integer, intent(in) :: Lin, R, index #ifdef __GFORTRAN__ type(real_pointer), dimension(:) :: Arr #else type(real_pointer), dimension(*) :: Arr #endif integer I, J, L real P type(real_pointer) :: temp L = Lin do I = L J = R P = Arr((L + R)/2)%p(index) do do while (Arr(I)%p(index) P) I = I + 1 end do do while (Arr(J)%p(index) P) J = J - 1 end do if (I = J) then Temp%p = Arr(I)%p Arr(I)%p = Arr(J)%p Arr(J)%p = Temp%p I = I + 1 J = J - 1 end if if (I J) exit end do if (L J) call QuickSortArr_Real(Arr, L, J, index); L = I if (I = R) exit end do end subroutine QuickSortArr_Real -- Summary: Valid pointer assigment code gives compilation errors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: antony at cosmologist dot info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #3 from loki at gcc dot gnu dot org 2008-03-05 11:09 --- Created an attachment (id=15262) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15262action=view) Avoid GET_ATTR_LENGTH when RECOG_MEMOIZED fails It seems this patch fixes the described problem on arm-eabi. I am also going to test it on other targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32-64
--- Comment #7 from ubizjak at gmail dot com 2008-03-05 11:10 ---
It looks that:
2006-11-03 Paolo Bonzini [EMAIL PROTECTED]
Steven Bosscher [EMAIL PROTECTED]
* fwprop.c: New file.
...
* cse.c (fold_rtx_subreg, fold_rtx_mem, fold_rtx_mem_1, find_best_addr,
canon_for_address, table_size): Remove.
(new_basic_block, insert, remove_from_table): Remove references to
table_size.
(fold_rtx): Process SUBREGs and MEMs with equiv_constant, make
simplification loop more straightforward by not calling fold_rtx
recursively.
(equiv_constant): Move here a small part of fold_rtx_subreg,
do not call fold_rtx. Call avoid_constant_pool_reference
to process MEMs.
removed this functionality. Specifically this part:
-/* If this is a constant pool reference, we can fold it into its
- constant to allow better value tracking. */
-if (base GET_CODE (base) == SYMBOL_REF
-CONSTANT_POOL_ADDRESS_P (base))
- {
- rtx constant = get_pool_constant (base);
- enum machine_mode const_mode = get_pool_mode (base);
- rtx new;
-
- if (CONSTANT_P (constant) GET_CODE (constant) != CONST_INT)
- {
- constant_pool_entries_cost = COST (constant);
- constant_pool_entries_regcost = approx_reg_cost (constant);
- }
-
- /* If we are loading the full constant, we have an
- equivalence. */
- if (offset == 0 mode == const_mode)
- return constant;
-
- /* If this actually isn't a constant (weird!), we can't do
- anything. Otherwise, handle the two most common cases:
- extracting a word from a multi-word constant, and
- extracting the low-order bits. Other cases don't seem
- common enough to worry about. */
- if (! CONSTANT_P (constant))
- return x;
-
- if (GET_MODE_CLASS (mode) == MODE_INT
-GET_MODE_SIZE (mode) == UNITS_PER_WORD
-offset % UNITS_PER_WORD == 0
-(new = operand_subword (constant,
- offset / UNITS_PER_WORD,
- 0, const_mode)) != 0)
- return new;
-
- if (((BYTES_BIG_ENDIAN
- offset == GET_MODE_SIZE (GET_MODE (constant)) - 1)
-|| (! BYTES_BIG_ENDIAN offset == 0))
-(new = gen_lowpart (mode, constant)) != 0)
- return new;
- }
This also explains why 4.2 doesn't fold HImode references (Other cases don't
seem common enough to worry about.).
Can we have this functionality back, perhaps also for Other cases, since
there are people that worry about them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug fortran/35471] New: gfortran build fails in libgfortran
gfortran build fails due to complex not being defined in kinds.h. Though the system has a complex.h, #define for complex is missing in it. Fix is to include #ifndef complex #define complex __complex__ #endif at top of kinds.h, or to explicitly check for complex type in libgfortran/configure.ac gmake[2]: Entering directory `/usr2/local/src/gcc-4.3-20080204/gcc-linux/i686-pc-linux-gnu/libgfortran' /bin/sh ../../../gcc/libgfortran/mk-sik-inc.sh '/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/gfortran -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2' selected_int_kind.inc || rm selected_int_kind.inc /bin/sh ../../../gcc/libgfortran/mk-srk-inc.sh '/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/gfortran -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2' selected_real_kind.inc || rm selected_real_kind.inc /bin/sh ../../../gcc/libgfortran/mk-kinds-h.sh '/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/gfortran -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2' kinds.h || rm kinds.h grep '^#' kinds.h kinds.inc grep '^#' ../../../gcc/libgfortran/c99_protos.h c99_protos.inc cp ../../../gcc/libgfortran/config/fpu-387.h fpu-target.h gmake all-am gmake[3]: Entering directory `/usr2/local/src/gcc-4.3-20080204/gcc-linux/i686-pc-linux-gnu/libgfortran' if /bin/sh ./libtool --tag=CC --mode=compile /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2 -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c -o fmain.lo ../../../gcc/libgfortran/fmain.c; \ then mv -f .deps/fmain.Tpo .deps/fmain.Plo; else rm -f .deps/fmain.Tpo; exit 1; fi libtool: compile: /usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/xgcc -B/usr2/local/src/gcc-4.3-20080204/gcc-linux/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2 -MT fmain.lo -MD -MP -MF .deps/fmain.Tpo -c ../../../gcc/libgfortran/fmain.c -fPIC -DPIC -o .libs/fmain.o In file included from ../../../gcc/libgfortran/libgfortran.h:211, from ../../../gcc/libgfortran/fmain.c:1: ./kinds.h:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'float' ./kinds.h:38: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'double' ./kinds.h:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'long' In file included from ../../../gcc/libgfortran/fmain.c:1: ../../../gcc/libgfortran/libgfortran.h:287: error: expected specifier-qualifier-list before 'GFC_COMPLEX_4' ../../../gcc/libgfortran/libgfortran.h:288: error: expected specifier-qualifier-list before 'GFC_COMPLEX_8' ../../../gcc/libgfortran/libgfortran.h:290: error: expected specifier-qualifier-list before 'GFC_COMPLEX_10' ../../../gcc/libgfortran/libgfortran.h:627: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ../../../gcc/libgfortran/libgfortran.h:628: error: 'internal_pack_c4' undeclared here (not in a function) ../../../gcc/libgfortran/libgfortran.h:628: warning: type defaults to 'int' in declaration of 'internal_pack_c4' ../../../gcc/libgfortran/libgfortran.h:630: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ../../../gcc/libgfortran/libgfortran.h:631: error: 'internal_pack_c8' undeclared here (not in a function) ../../../gcc/libgfortran/libgfortran.h:631: warning: type defaults to 'int' in declaration of 'internal_pack_c8' ../../../gcc/libgfortran/libgfortran.h:634: error: expected '=', ',', ';', 'asm' or
[Bug tree-optimization/35472] New: [4.3/4.4 Regression] tree DSE is broken
extern void abort (void);
extern void *memset (void *s, int c, __SIZE_TYPE__ n);
struct S { int i[16]; };
struct S *p;
void __attribute__((noinline))
foo(struct S *a, struct S *b) { a-i[0] = -1; p = b; }
void test (void)
{
struct S a, b;
memset (a.i[0], '\0', sizeof (a.i));
memset (b.i[0], '\0', sizeof (b.i));
foo (a, b);
*p = a;
*p = b;
if (b.i[0] != -1)
abort ();
}
int main()
{
test();
return 0;
}
tree DSE removes the *p = a store wrongly. Non-executable testcase:
struct S { int i[16]; };
struct S *p;
void foo(struct S *, struct S *);
void test (void)
{
struct S a, b;
foo (a, b);
*p = a;
*p = b;
}
--
Summary: [4.3/4.4 Regression] tree DSE is broken
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug tree-optimization/35472] [4.3/4.4 Regression] tree DSE is broken
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-05 13:19:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32-64
--- Comment #8 from bonzini at gnu dot org 2008-03-05 13:21 --- Should be handled by this code in simplify_subreg: /* A SUBREG resulting from a zero extension may fold to zero if it extracts higher bits that the ZERO_EXTEND's source bits. */ if (GET_CODE (op) == ZERO_EXTEND bitpos = GET_MODE_BITSIZE (GET_MODE (XEXP (op, 0 return CONST0_RTX (outermode); fwprop does not because the memory is written to. Can anyone run spec moving fwprop *before* CSE instead of after? -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||13724 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug rtl-optimization/35281] [4.3/4.4 Regression] multiply with 0 generated for 64*32-64
--- Comment #9 from bonzini at gnu dot org 2008-03-05 13:22 --- fwprop does not because the memory is written to (and fwprop does not do alias analysis). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #8 from dominiq at lps dot ens dot fr 2008-03-05 14:27 --- With revision 132897 on i686-apple-darwin9 I get: [ibook-dhum] f90/bug% gfc -c -frtl-abstract-sequences /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c: In function 'foo': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: error: unrecognizable insn: (insn 118/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [ibook-dhum] f90/bug% gfc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Thread model: posix gcc version 4.4.0 20080305 (experimental) (GCC) For gcc.c-torture/compile/pr11832.c I also get: [ibook-dhum] f90/bug% gfc -c -frtl-abstract-sequences /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function 'foo': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: error: unrecognizable insn: (insn 259/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #9 from loki at gcc dot gnu dot org 2008-03-05 14:36 --- (In reply to comment #8) With revision 132897 on i686-apple-darwin9 I get: ... unrecognizable insn: (insn 118/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: internal compiler error: Segmentation fault It seems to me it is the same problem as PR33642. Would you be so kind to check it again on i686-apple-darwin9 with the attached patch from PR33642? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug fortran/35473] New: internal compiler error
An internal compiler error comes up upon trying to build gfortran from a fresh download of the source tree on the PowerPc Macintosh (10.5.3) - make all-am /bin/sh ./libtool --tag=CC --mode=link /Users/dir/gfortran/ibin/./gcc/xgcc -B/Users/dir/gfortran/ibin/./gcc/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/bin/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/lib/ -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/include -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/sys-include -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -o libgfortranbegin.la -rpath /usr/local/gfortran/lib/gcc/powerpc-apple-darwin9.2.0/4.4.0 -static fmain.lo libtool: link: ar rc .libs/libgfortranbegin.a fmain.o libtool: link: ranlib -c .libs/libgfortranbegin.a libtool: link: creating libgfortranbegin.la libtool: link: ( cd .libs rm -f libgfortranbegin.la ln -s ../libgfortranbegin.la libgfortranbegin.la ) if /bin/sh ./libtool --tag=CC --mode=compile /Users/dir/gfortran/ibin/./gcc/xgcc -B/Users/dir/gfortran/ibin/./gcc/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/bin/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/lib/ -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/include -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT maxloc1_4_r16.lo -MD -MP -MF .deps/maxloc1_4_r16.Tpo -c -o maxloc1_4_r16.lo `test -f '../../../gcc/libgfortran/generated/maxloc1_4_r16.c' || echo '../../../gcc/libgfortran/'`../../../gcc/libgfortran/generated/maxloc1_4_r16.c; \ then mv -f .deps/maxloc1_4_r16.Tpo .deps/maxloc1_4_r16.Plo; else rm -f .deps/maxloc1_4_r16.Tpo; exit 1; fi libtool: compile: /Users/dir/gfortran/ibin/./gcc/xgcc -B/Users/dir/gfortran/ibin/./gcc/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/bin/ -B/usr/local/gfortran/powerpc-apple-darwin9.2.0/lib/ -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/include -isystem /usr/local/gfortran/powerpc-apple-darwin9.2.0/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT maxloc1_4_r16.lo -MD -MP -MF .deps/maxloc1_4_r16.Tpo -c ../../../gcc/libgfortran/generated/maxloc1_4_r16.c -fno-common -DPIC -o .libs/maxloc1_4_r16.o ../../../gcc/libgfortran/generated/maxloc1_4_r16.c: In function 'mmaxloc1_4_r16': ../../../gcc/libgfortran/generated/maxloc1_4_r16.c:220: internal compiler error: in memory_address, at explow.c:492 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [maxloc1_4_r16.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libgfortran] Error 2 make: *** [all] Error 2 [dranta:~/gfortran/ibin] dir% -- Summary: internal compiler error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.10.0 (10.5.3) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35473
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-03-05 14:39 --- (In reply to comment #9) To answer the question, when the test fail dlog10 returns 0, but to get that you need some intermediate steps. Can you show us your program that shows dlog10 returning 0? The problem has the usual signature of something reading/writing where it should not. Seems implausible, there's no array. I'm more tempted to suspect a library numerical issue or an alignment issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug tree-optimization/35472] [4.3/4.4 Regression] tree DSE is broken
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-05 14:56 --- Patch in testing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug tree-optimization/35472] [4.3/4.4 Regression] tree DSE is broken
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-05 14:45 --- We have # VUSE p_7 p.0_1 = p; # a_11 = VDEF a_8 # b_12 = VDEF b_9 # SMT.5_13 = VDEF SMT.5_10 *p.0_1 = a; # a_14 = VDEF a_11 # b_15 = VDEF b_12 # SMT.5_16 = VDEF SMT.5_13 *p.0_1 = b; This is actually a case of PR34459 and it is its testcase that actually fails with the fix for PR27799. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34459 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug fortran/35474] New: [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE
$ cat test_mod.f90 module h5global integer i integer j common /c/ i equivalence (i, j) private end module h5global program bug use h5global end $ gfortran -c test_mod.f90 test_mod.f90:10.14: use h5global 1 Internal Error at (1): free_pi_tree(): Unresolved fixup $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20080221/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20080221/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20080221 (experimental) [trunk revision 132519] (GCC) It requires the interaction of common, equivalence and private to make it fail. This is a 4.3/4.4 regression, and probably a bad one because it can be triggered by HDF, which is widely used. -- Summary: [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35474
[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-05 15:27 --- This is done by several passes through the magics of fold_stmt_r: case ARRAY_REF: /* If we are not processing expressions found within an ADDR_EXPR, then we can fold constant array references. */ if (!*inside_addr_expr_p) t = fold_read_from_constant_string (expr); else t = NULL; break; we should remember if we are visiting the LHS of an expression here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-05 15:27:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug tree-optimization/35468] LHS of assignment can be folded to a constant causing ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-05 15:28 --- Of course the testcase invokes undefined behavior at runtime. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code, wrong- ||code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #11 from dominiq at lps dot ens dot fr 2008-03-05 15:29 --- (In reply to comment #10) [ibook-dhum] f90/bug% cat nist_827_red_2.f program fm827 double precision avd, bvd, cvd, dvd, dvcorr cvd = 10.0d0 dvd = 6.0d0 dvd = dlog10(cvd) - 2.0d0 / 1 (dexp(dvd) + 1.0d0) avd = dvd - dtanh(3.0d0) if (abs(avd) 0.50d-09) then print *, fails print *, avd=,avd, should be: , 0.0_8 print *, dlog10(cvd), dexp(dvd) else print *, passes end if end [ibook-dhum] f90/bug% gfc -m64 nist_827_red_2.f [ibook-dhum] f90/bug% a.out fails avd= -1.0 should be:0. 0. 0.99506696128579508 The first real of the last line is dlog10(cvd) with cvd = 10.0d0, so it should be 1.0 and not 0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-05 15:08:55 date|| Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35474
[Bug fortran/35474] [4.3/4.4 regression] Reading module file with COMMON and EQUIVALENCE
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-05 15:32 --- Possibly caused by the following patch. It fails for me around 30/31 May. Patch: http://gcc.gnu.org/ml/fortran/2007-05/msg00504.html r125216 | pault | 2007-05-31 09:45:50 +0200 (Thu, 31 May 2007) | 13 lines 2007-05-31 Paul Thomas [EMAIL PROTECTED] PR fortran/32103 * module.c (mio_symtree_ref): If an equivalence group member is not used, give it a hidden symbol and set the pointer_info. (load_equiv): Only free the equivalence if none of the members are used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35474
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #10 from dominiq at lps dot ens dot fr 2008-03-05 15:40 --- (In reply to comment #9) It seems to me it is the same problem as PR33642. Would you be so kind to check it again on i686-apple-darwin9 with the attached patch from PR33642? I am currently regtesting, I'll apply the patch as soon as it's finished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug fortran/35473] internal compiler error
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-05 16:01 --- *** This bug has been marked as a duplicate of 35373 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Version|4.3.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35473
[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-05 16:01 --- *** Bug 35473 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-05 16:13 --- Fixed on the trunk, waiting for 4.3.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.3 4.4.0 Priority|P1 |P2 Summary|[4.3/4.4 Regression] tree |[4.3 Regression] tree DSE is |DSE is broken |broken Target Milestone|4.3.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-05 16:13 --- Subject: Bug 35472 Author: rguenth Date: Wed Mar 5 16:13:04 2008 New Revision: 132899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132899 Log: 2008-03-05 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/35472 * tree-ssa-dse.c (dse_optimize_stmt): Do not delete a store whose single use_stmt has a overlapping set of loaded and stored symbols as that use_stmt might be a noop assignment then. * gcc.c-torture/execute/pr35472.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr35472.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35472
[Bug fortran/35475] New: gfortran fails to compile valid code with ICE segfault
gfortran fails to compile valid code, leads to ICE segfault, Code compiles fine under 4.1.2 . command used: gfortran -v -save-temps -c -ffree-form ice.f OUTPUT: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.3/configure --prefix=/scratch/sjb/local Thread model: posix gcc version 4.2.3 /scratch/sjb/local/libexec/gcc/i686-pc-linux-gnu/4.2.3/f951 ice.f -quiet -dumpbase ice.f -mtune=generic -auxbase ice -version -ffree-form -I /scratch/sjb/local/lib/gcc/i686-pc-linux-gnu/4.2.3/finclude -o ice.s GNU F95 version 4.2.3 (i686-pc-linux-gnu) compiled by GNU C version 4.2.3. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129260 ice.f: In function subtwo: ice.f:51: internal compiler error: in fold_convert, at fold-const.c:2248 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: gfortran fails to compile valid code with ICE segfault Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: s dot binnie at ucl dot ac dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35475] gfortran fails to compile valid code with ICE segfault
--- Comment #1 from s dot binnie at ucl dot ac dot uk 2008-03-05 17:26 --- Created an attachment (id=15263) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15263action=view) Testcase (reduced from proprietary code). Testcase (reduced from proprietary code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35475] gfortran fails to compile valid code with ICE erro in fold-const.c
--- Comment #2 from s dot binnie at ucl dot ac dot uk 2008-03-05 17:34 --- (In reply to comment #0) gfortran fails to compile valid code, leads to ICE segfault, Code compiles fine under 4.1.2 . command used: gfortran -v -save-temps -c -ffree-form ice.f OUTPUT: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.3/configure --prefix=/scratch/sjb/local Thread model: posix gcc version 4.2.3 /scratch/sjb/local/libexec/gcc/i686-pc-linux-gnu/4.2.3/f951 ice.f -quiet -dumpbase ice.f -mtune=generic -auxbase ice -version -ffree-form -I /scratch/sjb/local/lib/gcc/i686-pc-linux-gnu/4.2.3/finclude -o ice.s GNU F95 version 4.2.3 (i686-pc-linux-gnu) compiled by GNU C version 4.2.3. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129260 ice.f: In function subtwo: ice.f:51: internal compiler error: in fold_convert, at fold-const.c:2248 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Sorry it's not a segfault (that was yesterdays problem...) as the output shows it's a problem with fold-const.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35476] New: Accepts invalid: USE/host association of generics with same specifics
Found the following on the J3 Fortran list. I think the program below is invalid for the reasons given by Bill Long, but it has not finally decided yet (on J3). (The question/program comes from Sun) Current status: - openf95 and sunf95 reject it - ifort, gfortran, NAG f95, and g95 accept it Bill Long writes that he tested two non-Sun compilers, of which two gave an error and two did not. Craig diged up from the standard: | Use association is defined in section 11.2.1. Host association is | covered in section 16.4.1.3. The second paragraph starts with this sentence | [411:9-10]: If an entity that is accessed by use association has the same | nongeneric name as a host entity, the host entity is inaccessible by that | name. However, as Bill notes: | I think that issuing the error is valid. Generic interfaces merge | together their lists of specifics when more than one with the same | generic name is visible. Whether that visibility comes through host | association or use association should not matter. Craig's citation from | f03 explicitly says nongeneric intentionally, and does not apply in | this case. MODULE M1 INTERFACE SUBR MODULE PROCEDURE SUBR1 END INTERFACE CONTAINS SUBROUTINE SUBR1 END SUBROUTINE END MODULE M2 INTERFACE SUBR MODULE PROCEDURE SUBR2 END INTERFACE CONTAINS SUBROUTINE SUBR2 END SUBROUTINE END PROGRAM MAIN USE M1 CALL S CONTAINS SUBROUTINE S USE M2 CALL SUBR END SUBROUTINE END -- Summary: Accepts invalid: USE/host association of generics with same specifics Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug fortran/35475] [4.2 Regression] gfortran fails to compile valid code with ICE erro in fold-const.c
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-05 17:51 --- Works on 4.1.2 (release), trunk (20080225) and 4.3 branch (20080219), fails for 4.2.4 (20080222). -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Known to fail||4.2.4 Known to work||4.1.2 4.3.0 4.4.0 Summary|gfortran fails to compile |[4.2 Regression] gfortran |valid code with ICE erro in |fails to compile valid code |fold-const.c|with ICE erro in fold- ||const.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35475] [4.2 Regression] gfortran fails to compile valid code with ICE erro in fold-const.c
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-05 17:55 --- Thanks for the report. I can reproduce the problem with 4.2.3, however, it seems to be fixed in GCC/gfortran 4.3.0rc2 (and 4.4.0) - and as Daniel noted it used to worked with 4.1.3. GCC 4.3.0 is supposted to be released at the end of this week (currently, we have release candidate 2). Any chance that you could upgrade your GCC and try again? Despite being a regression, I'm not sure it will be fixed soon as we need to find the fix first. Binaries and a description how to build GCC from source can be found at http://gcc.gnu.org/wiki/GFortranBinaries Depending on your Linux distribution, they might have already experimental GCC 4.3.0 packages somewhere. Changelog: http://gcc.gnu.org/gcc-4.3/changes.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.4 |4.1.3 4.2.2 Known to work|4.1.2 4.3.0 4.4.0 |4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35475] [4.2 Regression] gfortran fails to compile valid code with ICE erro in fold-const.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-05 17:59 --- (In reply to comment #4) GCC 4.3.0 is supposted to be released at the end of this week (currently, we have release candidate 2). It is actually very closer to release than the end of the week, in fact it is being uploaded to the FTP sites right now :). The official announcement will be made after some of the mirrors pick it up. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #12 from dominiq at lps dot ens dot fr 2008-03-05 20:45 ---
I have reported the bug to Apple, it is radar 5782719 with the following test:
[ibook-dhum] f90/bug% cat nist_827_c.c
#include stdio.h
#include stdlib.h
#include math.h
#include float.h
int main() {
double avd, bvd, cvd, dvd, dvcorr;
cvd = 10.0;
dvd = 6.0;
dvd = log10(cvd) - 2.0/(exp(dvd)+1.0);
avd = dvd - tanh(3.0);
if (abs(avd) 0.5e-9)
{
printf(fails\n);
printf(avd=%g, should be 0.0\n, avd);
printf(%g, %g\n, log10(cvd), exp(dvd));
}
else printf(pass\n);
}
[ibook-dhum] f90/bug% gcc -m64 nist_827_c.c
[ibook-dhum] f90/bug% a.out
fails
avd=-1, should be 0.0
0, 0.995067
[ibook-dhum] f90/bug% gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #11 from dominiq at lps dot ens dot fr 2008-03-05 20:53 --- Note that I see the problem reported in comment #8 on powerpc-apple-darwin9 too ((insn 139[address=afafafaf pc=003bf7a0]). I have applied the patch from PR33642 and the manual tests pass. I am starting a regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #8 from gnu_andrew at member dot fsf dot org 2008-03-05 21:03 --- Created an attachment (id=15264) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15264action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #9 from gnu_andrew at member dot fsf dot org 2008-03-05 21:03 --- Created an attachment (id=15265) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15265action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #10 from gnu_andrew at member dot fsf dot org 2008-03-05 21:04 --- Created an attachment (id=15266) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15266action=view) Move towards a CPStringBuilder-using code base -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
-- gnu_andrew at member dot fsf dot org changed: What|Removed |Added Target Milestone|--- |0.98 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-03-05 21:27 --- (In reply to comment #12) I have reported the bug to Apple, it is radar 5782719 Closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35285
[Bug c++/35477] New: Compiling error with template subclass of a variadic template class
The following code fails to compile on gcc-4.3.0-RC2 with -std=c++0x
template class...ARGS struct tuple {};
template class A, class B struct test {};
template class... ARGS, class B struct testB, tupleARGS...
{
template class T struct inside {};
};
g++ exits saying:
error: parameter pack ARGS must be at the end of the template parameter list
on line 5 (where struct inside is defined)
By removing the struct inside definition, it compiles fine.
--
Summary: Compiling error with template subclass of a variadic
template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35477
[Bug fortran/35475] [4.2 Regression] gfortran fails to compile valid code with ICE erro in fold-const.c
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-05 21:43 --- Simon and Tobias, (In reply to comment #4) Thanks for the report. I can reproduce the problem with 4.2.3, however, it seems to be fixed in GCC/gfortran 4.3.0rc2 (and 4.4.0) - and as Daniel noted it used to worked with 4.1.3. I was responsible for much of the variability and regressions in this area. Unfortunately, in spite of our my endeavours, the testsuite did not keep track of the regressions that I was generating. I think that is OK now and that the regression in 4.2.3 was cause by fixing things that 4.1.3 did not dream about. 4.3.x and 4.4.0 are now much better. Please accept my apologies for the temporary breakage. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35475
[Bug fortran/35471] libgfortran fails with nonstandard complex.h
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-03-05 21:45 --- What kind of system do you have, to have a complex.h without complex defined in it? (sounds kind of useless) I suggest the following patch: Index: libgfortran.h === --- libgfortran.h (revision 132578) +++ libgfortran.h (working copy) @@ -42,10 +42,12 @@ #if HAVE_COMPLEX_H # include complex.h -#else -#define complex __complex__ #endif +#if !defined(HAVE_COMPLEX_H) || !defined(complex) +# define complex __complex__ +#endif + #include ../gcc/fortran/libgfortran.h #include c99_protos.h -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Summary|gfortran build fails in |libgfortran fails with |libgfortran |nonstandard complex.h http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-05 21:53:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug fortran/35470] Valid pointer assigment code gives compilation errors
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-03-05 22:00 --- Confirmed as rejecting valid code, reduced testcase is: subroutine sub(arr) type real_pointer real, pointer :: p(:) end type real_pointer type(real_pointer), dimension(*) :: arr real, pointer :: p(:) p = arr(1)%p end subroutine $ gfortran -c a.f90 a.f90:9.7: p = arr(1)%p 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'arr' at (1) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-03-05 22:00:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
--- Comment #1 from pault at gcc dot gnu dot org 2008-03-05 22:05 --- (In reply to comment #0) Found the following on the J3 Fortran list. I think the program below is invalid for the reasons given by Bill Long, but it has not finally decided yet (on J3). (The question/program comes from Sun) This worries me a lot. If you recall, I did a lot of work on this and you acted as reviewer/collaborator. We concluded that, in general, the precedence rules should be accomplished without warnings or errors. Several of the exmaples in the standard guided us in this. I'll go and look at the correspondence. Paul who is still struggling and losing the fight with memory leaks in allocatable components. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #12 from dominiq at lps dot ens dot fr 2008-03-05 22:26 --- With the patch from PR33642, gcc regtested fine (with the usual failures) on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug tree-optimization/35402] Store CCP will not inline static const variable which is default initialized
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-05 23:40 --- (In reply to comment #3) Please change tree-ssa-sccvn.c:try_to_simplify accordingly (eventually that should use a common helper function to extract a constant initializer for the tcc_reference case, too). Thanks! There is already a helper function in tree-ssa-ccp.c: get_symbol_constant_value . This is what I am changing if tree-ssa-sccvn.c:try_to_simplify wants to use it, it should too. I think there are too many duplicated functions all around really. This is just one example. -- PInski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35402
[Bug ada/35186] implicit assumption about alignment of DImode
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-03-06 00:45 --- Subject: Bug 35186 Author: ebotcazou Date: Thu Mar 6 00:44:11 2008 New Revision: 132963 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132963 Log: PR ada/35186 * decl.c (maybe_pad_type): Avoid padding an integral type when bumping its alignment is sufficient. Added: trunk/gcc/testsuite/gnat.dg/specs/pack33.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
[Bug ada/35186] implicit assumption about alignment of DImode
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-03-06 00:48 --- This should be OK now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||03/msg00383.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #16 from nightstrike at gmail dot com 2008-03-06 03:00 --- Created an attachment (id=15267) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15267action=view) Preprocssed source for the testcase mentioned I took the code that I mentioned in the first post in this bug and I compiled it with g++ --save-temps. This is the result. It outputed this to stderr: built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-03-06 04:50 --- What is the Fortran test case that makes this is a gfortran issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug c++/35159] g++ and gfortran inoperable with no error message
--- Comment #18 from nightstrike at gmail dot com 2008-03-06 05:09 --- (In reply to comment #17) What is the Fortran test case that makes this is a gfortran issue? PROGRAM HelloWorld WRITE(*,*) Hello World! END PROGRAM I haven't tested that again with the latest changes that Joesph Myers has put into gcc, so I'll do it again as soon as I rebuild. But yeah, hello world doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-06 07:00 --- Thread starts here: http://j3-fortran.org/pipermail/j3/2008-March/001103.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #13 from dominiq at lps dot ens dot fr 2008-03-06 07:33 ---
With the patch from PR33642 on top of rev. 132950, the test suite passed
without regression on i686-apple-darwin9. However on powerpc-apple-darwin9 I
get now:
[karma] f90/bug% gfc -c -frtl-abstract-sequences
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c: In function
'foo':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: error:
insn does not satisfy its constraints:
(jump_insn 145 87 146
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:32 (set (pc)
(reg:SI 6 r6)) 519 {*indirect_jumpsi} (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr33009.c:36: internal
compiler error: in final_scan_insn, at final.c:2552
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[karma] f90/bug% gfc -c -frtl-abstract-sequences
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
'foo':
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: error:
insn does not satisfy its constraints:
(jump_insn 322 95 323
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:16 (set (pc)
(reg:SI 3 r3)) 519 {*indirect_jumpsi} (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30: internal
compiler error: in final_scan_insn, at final.c:2552
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
