[Bug tree-optimization/32328] [4.2 Regression] -fstrict-aliasing causes skipped code
--- Comment #25 from giovannibajo at libero dot it 2007-09-05 06:47 --- Daniel, can we backport this patch to 4.2, please? It's a P1 regression! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-09-05 06:17 --- (In reply to comment #1) > I think I'll let Kaveh fix this one... To what exactly do I owe this honor? :-) AFAICT, this is a -Wwrite-strings error caused by a patch by FX: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02280.html A quick fix might be to do ASTRDUP on the INIT_ENVIRONMENT string. It's okay to use stack space for putenv strings here because we're in main(). However I seem to recall a problem with alloca passed as a function argument in some ancient version of gcc. So it'll need an intermediate tmp variable, or use xstrdup to avoid alloca. Another option would be to constify xputenv and use CONST_CAST on the argument passed to putenv. A third option would be to constify xputenv and fixinclude putenv on those platforms where it isn't const. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #4 from ian at airs dot com 2007-09-05 06:03 --- I haven't looked further at this since this message: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01166.html Testing DECL_EXTERNAL_LINKAGE_P does not make any difference: the compiler still crashes. The decl in question is unit size align 32 symtab 0 alias set -1 canonical type 0xb7d378dc precision 32 min max > readonly used private static tree_1 tree_2 tree_3 nonlocal decl_3 decl_5 decl_6 SI file /home/iant/foo1.cc line 8 size unit size align 32 context initial template-info 0xb7d3c444 chain > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #26 from jakub at gcc dot gnu dot org 2007-09-05 05:46 --- This is just one bug, present in GCC 4.1 and onwards, no need to have several bug ids. tree-ssa-alias.c just uses ipa_type_escape_field_does_not_clobber_p incorrectly, it asks an unrelated question and based on the answer decides if things can or can't alias. There are testcases where this bug exhibits only in some gcc versions (e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136#c7 ), because it depends on what exactly other optimization passes do, and other testcases, like #c8, which fail in all 4.1+ GCCs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
--- Comment #15 from ian at airs dot com 2007-09-05 05:34 --- Fixed. -- ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
--- Comment #14 from ian at gcc dot gnu dot org 2007-09-05 05:31 --- Subject: Bug 33029 Author: ian Date: Wed Sep 5 05:31:37 2007 New Revision: 128119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128119 Log: PR middle-end/33029 * lower-subreg.c (resolve_clobber): If we remove a REG_LIBCALL note, remove the associated REG_RETVAL note. Modified: trunk/gcc/ChangeLog trunk/gcc/lower-subreg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains "version"
--- Comment #5 from belyshev at depni dot sinp dot msu dot ru 2007-09-05 05:10 --- Fixed. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug libstdc++/31906] "-Xcompiler" is inserted after "-Xlinker" when building libstdc++
--- Comment #13 from prj-bugzilla-gcc at multivac dot cwru dot edu 2007-09-05 04:49 --- (In reply to comment #12) > I'd certainly like to see this fixed in 4.2.2 Will someone be reviewing and committing this before 4.2.2? I posted it to gcc-patches with a ChangeLog entry, but there was no response: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00920.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains "version"
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-09-05 02:24 --- Since a patch has been checked in, can this issue be closed? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug libgcj/33263] [4.3 regression] libjava testsuite failures on alpha-linux
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263
[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug c++/33213] [4.3 regression] Broken diagnostic: 'type_pack_expansion' not supported by dump_decl
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33213
[Bug c++/33207] [4.3 regression] ICE redeclaring namespace as struct
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33207
[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
[Bug middle-end/33199] [4.3 Regression] tr1/2_general_utilities/shared_ptr/assign/auto_ptr.cc
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33199
[Bug c++/33185] [4.3 Regression] ICE: canonical types differ for identical types T [] and T []
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33185
[Bug target/33184] [4.3 Regression] m32c: ostream.tcc:92: error: unable to find a register to spill in class 'A_REGS'
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33184
[Bug tree-optimization/33146] [4.3 Regression] ICE in build_polynomial_chrec, at tree-chrec.h:136
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33146
[Bug tree-optimization/33140] [4.3 Regression] ICE in build2_stat, at tree.c:3115
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
[Bug target/33138] [4.3 Regression] rejects valid? assembler, segfaults
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33138
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug bootstrap/33309] gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualifiers from pointer target type
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-05 01:50 --- I think I'll let Kaveh fix this one... On hpux and in libiberty, putenv takes a const char * while on other os's it takes a char *. xputenv doesn't do anything that would affect the constantness of its argument. Thus, it doesn't seem reasonable to do something ugly to the definition of INIT_ENVIRONMENT in pa64-hpux.h to resolve this regression. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at caip dot rutgers ||dot edu Summary|gcc.c:6236: error: passing |gcc.c:6236: error: passing |argument 1 of 'xputenv' |argument 1 of 'xputenv' |discards qualif |discards qualifiers from |iers from pointer target|pointer target type |type| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug c++/33118] [4.3 Regression] #'argument_pack_select' not supported by dump_expr#
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33118
[Bug tree-optimization/33107] [4.3 regression] segfault in garbage collector
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33107
[Bug middle-end/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-09-05 01:31 --- I'm all for removing optimization options if we don't ever want to turn them off. Fewer options would be better... -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
gcc-bugs@gcc.gnu.org
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-09-05 01:28 --- To answer Jakub's question: > So, what can be done to speed up acceptance of this? Jim is a GWP maintainer, so once he's happy the patch can go in. Testing on IA64 definitely seems like a good step. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #13 from zadeck at naturalbridge dot com 2007-09-05 01:24 --- Subject: Re: [4.3 Regression] ICE with -O2 -fsee jakub at gcc dot gnu dot org wrote: > --- Comment #12 from jakub at gcc dot gnu dot org 2007-09-04 23:37 > --- > Fixed. > > > jakub thanks for doing this. The changes to df are fine, but i think that it exceeds my authority to approve more than that. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug c++/33239] [4.1/4.2/4.3 Regression] internal compiler error in instantiate_class_template, at cp/pt.c:5666
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33239
[Bug c/33238] [4.1/4.2/4.3 Regression] ICE on statement expression using variable-sized structure in tree_low_cst, at tree.c:4502
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33238
[Bug c++/33210] [4.1/4.2 Regression] Broken diagnostics: 'bound_template_template_parm' not supported by pp_cxx_unqualified_id/dump_decl
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-09-05 01:10 --- It would be nice to fix this on the 4.2 branch, but certainly not a priority. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33210
[Bug middle-end/33195] [4.2 Regression] ICE: calc_dfs_tree, at dominance.c:374
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33195
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #25 from mmitchel at gcc dot gnu dot org 2007-09-05 01:08 --- It's not clear to me what's going on in this PR. At one point, Jakub seems to be saying that 4.2 does a better job than 4.1, which would suggest that this is just a 4.1.x PR? Can we split this into one PR for 4.1-only issues, and another one or two, for 4.2 and/or 4.3 issues? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug bootstrap/33309] New: gcc.c:6236: error: passing argument 1 of 'xputenv' discards qualif iers from pointer target type
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -g -O2 -DIN_GCC -W
-Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common
-DHAV
E_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/opt/gnu64/gcc/gcc-4.3.0/include
-I../../gc
c/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
\
-DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/opt/gnu64/
gcc/gcc-4.3.0/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/opt/gnu64/gcc/gcc-4.3.0/li
bexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.3.0\"
-DDEFAULT_TARGET_MACHINE=\"hppa6
4-hp-hpux11.11\" -DSTANDARD_BINDIR_PREFIX=\"/opt/gnu64/gcc/gcc-4.3.0/bin/\"
-DTO
OLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test "yes"
!
= "yes" || echo "-DENABLE_SHARED_LIBGCC"` \
-c ../../gcc/gcc/gcc.c -o gcc.o)
cc1: warnings being treated as errors
../../gcc/gcc/gcc.c: In function 'main':
../../gcc/gcc/gcc.c:6236: error: passing argument 1 of 'xputenv' discards
qualif
iers from pointer target type
Ugh.
--
Summary: gcc.c:6236: error: passing argument 1 of 'xputenv'
discards qualif
iers from pointer target type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa64-hp-hpux11*
GCC host triplet: hppa64-hp-hpux11*
GCC target triplet: hppa64-hp-hpux11*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33309
[Bug c++/33094] [4.2/4.3 Regression] ICE on valid C++ virtual template static member in anonymous namespace
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-09-05 01:00 --- Ian, I know that we talked about this on the mailing list at one point. Did this get resolved? Does changing the assert to check DECL_EXTERNAL_LINKAGE_P instead of DECL_EXTERNAL help? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33094
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-09-05 00:58 --- Do we have any way to work out whether this is still a problem? Richard seems to think the bug has been fixed, but Pascal is still seeing the problem, apparently. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug libfortran/33225] Missing last digit in some formatted output (on 32bit targets), per kind write_float
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2007-09-05 00:51 --- Subject: Bug 33225 Author: jvdelisle Date: Wed Sep 5 00:51:18 2007 New Revision: 128114 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128114 Log: 2007-03-04 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/33225 * io/write.c (stdbool.h): Add include. (sign_t): Move typedef to new file write_float.def. Include write_float.def. (extract_real): Delete. (calculate_sign): Delete. (calculate_exp): Delete. (calculate_G_format): Delete. (output_float): Delete. (write_float): Delete. * io/write_float.def (calculate_sign): Added. (output_float): Refactored to be independent of kind and added to this file for inclusion. (write_infnan): New function to write "Infinite" or "NaN" depending on flags passed, independent of kind. (CALCULATE_EXP): New macro to build kind specific functions. Use it. (OUTPUT_FLOAT_FMT_G): New macro, likewise. Use it. (DTOA, DTOAL): Macros to implement "decimal to ascii". (WRITE_FLOAT): New macro for kind specific write_float functions. (write_float): Revised function to determine kind and use WRITE_FLOAT to implement kind specific output. Added: trunk/libgfortran/io/write_float.def Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33225
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug middle-end/32575] [4.2/4.3 regression] With -ftree-vrp miscompiles a single line of code in SQLite
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
[Bug tree-optimization/32544] [4.2 Regression] miscompiles Mesa's r300 DRI driver with -ftree-vrp
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug fortran/33307] I/O read/positioning problem
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-09-05 00:11 --- I have been waiting for this to emerge. We knew there was a problem somewhere. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-05 00:11:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-04 23:37 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug tree-optimization/33017] [4.3 Regression] tree check fail for legal code
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-04 23:35 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #11 from jakub at gcc dot gnu dot org 2007-09-04 23:31 --- Subject: Bug 32300 Author: jakub Date: Tue Sep 4 23:31:11 2007 New Revision: 128108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128108 Log: PR rtl-optimization/32300 * see.c (see_copy_insn): New function. (see_def_extension_not_merged, see_merge_one_use_extension, see_merge_one_def_extension): Use it. Avoid changing PREV_INSN/NEXT_INSN chains directly, insted emit insns into sequences. Call df_insn_delete on temporary insns that won't be emitted into the insn stream. (rest_of_handle_see): Turn off DF_DEFER_INSN_RESCAN and run df_process_deferred_rescans () before run_fast_dce. Modified: trunk/gcc/ChangeLog trunk/gcc/see.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug tree-optimization/33017] [4.3 Regression] tree check fail for legal code
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-04 23:30 --- Subject: Bug 33017 Author: jakub Date: Tue Sep 4 23:29:58 2007 New Revision: 128107 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128107 Log: PR tree-optimization/33017 * tree-data-ref.c (split_constant_offset) : Don't recurse for pure or const function calls. * gcc.dg/pr33017.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33017.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-04 22:00 --- This works on the trunk (which is 4.3.0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug fortran/33308] gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
--- Comment #1 from t_nissie at yahoo dot co dot jp 2007-09-04 21:54 --- Created an attachment (id=14157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14157&action=view) compile: gfortran reshapetest.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33308
[Bug fortran/33308] New: gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array
I got ICE on i686-pc-linux-gnu, x86_64-unknown-linux-gnu and ia64-unknown-linux-gnu with gfortran 4.2.1. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.1 $ cat reshapetest.f90 ! reshapetest.f90 -*-f90-*- !! function f() implicit none real*8 :: f(3,3) f(:,:) = 1.0d0 end function f program reshapetest implicit none real*8, allocatable :: c(:,:) real*8, parameter :: one(3,3) = reshape((/1.0d0, 0.0d0, 0.0d0, & 0.0d0, 1.0d0, 0.0d0, & 0.0d0, 0.0d0, 1.0d0/),(/3,3/)) interface function f() implicit none real*8 :: f(3,3) end function f end interface allocate(c(3,3)) c(:,:) = one(:,:) + f() ! internal compiler error write(6,'(3f4.1)') c(:,:) end program reshapetest $ gfortran reshapetest.f90 reshapetest.f90: In function 'MAIN__': reshapetest.f90:21: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1467 : $ g95 reshapetest.f90 $ ./a.out 2.0 1.0 1.0 1.0 2.0 1.0 1.0 1.0 2.0 -- Summary: gfortran 4.2.1 ICE on allocated_array = reshaped_parameter_array + function_returning_array Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t_nissie at yahoo dot co dot jp 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=33308
[Bug libgcj/33278] [4.3 Regression] libjava fails to compile if configure argument contains "version"
--- Comment #3 from doko at gcc dot gnu dot org 2007-09-04 21:32 --- Subject: Bug 33278 Author: doko Date: Tue Sep 4 21:32:41 2007 New Revision: 128104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128104 Log: 2007-09-05 Matthias Klose <[EMAIL PROTECTED]> PR libgcj/33278 * configure.ac: Robustify extraction of gcj version. * configure: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33278
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-09-04 21:03 --- This one should be fairly straightforward. Mine :-) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-04 10:51:29 |2007-09-04 21:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug c++/31419] [4.1/4.2/4.3 regression] template user defined conversion operator instantiated for conversion to self
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-04 20:18 --- Subject: Bug 31419 Author: jason Date: Tue Sep 4 20:18:05 2007 New Revision: 128102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128102 Log: PR c++/31419 * call.c (reference_binding): Don't look for user-defined conversions to the same type. Added: trunk/gcc/testsuite/g++.dg/conversion/self1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug fortran/33307] I/O read/positioning problem
--- Comment #1 from anlauf at gmx dot de 2007-09-04 20:00 --- Created an attachment (id=14156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14156&action=view) Demo code Use with the file "gfcbug69.nml" from the bug description (3 lines), and compare with a run with the first line of "gfcbug69.nml" removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug fortran/33307] New: I/O read/positioning problem
The attached program exhibits a strange problem with gfortran when repeatedly trying to position within an input file, and which I have been hunting for a long time. The program is supposed to work as follows: - open input file - do - rewind - repeatedly search for lines containing a special text - end do The program always succeeds in finding the occurence of the first text, but fails to find the second text if the first text does *not* occur on the first text line. Example 1: % cat gfcbug69.nml ! ***Remove this line*** &FOOfile='foo' / &BARfile='bar' / % gfc -g -Wall -std=f2003 gfcbug69.f90 % ./a.out inquire: after OPEN: position = ASIS nextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: FOO position_nml: SUCCESS! line= &FOOfile='foo' / inquire: after position_nml: position = ASIS nextrec = 0 *** Found: &FOOfile='foo' / position_nml: Scanning for: FOO position_nml: FAIL: ios= -1 inquire: after position_nml: position = APPENDnextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 inquire: after position_nml: position = REWINDnextrec = 0 -- Removing the indicated line from the text file leads to: % ./a.out inquire: after OPEN: position = ASIS nextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: FOO position_nml: SUCCESS! line= &FOOfile='foo' / inquire: after position_nml: position = REWINDnextrec = 0 *** Found: &FOOfile='foo' / position_nml: Scanning for: FOO position_nml: FAIL: ios= -1 inquire: after position_nml: position = APPENDnextrec = 0 -- inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR position_nml: SUCCESS! line= &BARfile='bar' / inquire: after position_nml: position = ASIS nextrec = 0 *** Found: &BARfile='bar' / position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 inquire: after position_nml: position = ASIS nextrec = 0 -- Comparing the two results shows: % diff -u out.fail out.success --- out.fail2007-09-04 21:31:22.0 +0200 +++ out.success 2007-09-04 21:31:14.0 +0200 @@ -4,7 +4,7 @@ position_nml: Scanning for: FOO position_nml: SUCCESS! line= &FOOfile='foo' / -inquire: after position_nml: position = ASIS nextrec = 0 +inquire: after position_nml: position = REWINDnextrec = 0 *** Found: &FOOfile='foo' / @@ -15,6 +15,12 @@ inquire: after REWIND: position = REWINDnextrec = 0 position_nml: Scanning for: BAR +position_nml: SUCCESS! line= &BARfile='bar' / +inquire: after position_nml: position = ASIS nextrec = 0 + + *** Found: &BARfile='bar' / + +position_nml: Scanning for: BAR position_nml: FAIL: ios= -1 -inquire: after position_nml: position = REWINDnextrec = 0 +inquire: after position_nml: position = ASIS nextrec = 0 -- For some reason the file position after attempting to find the second text is still "REWIND". This may only be a cosmetic problem, but it could be a hint towards the source of the problem. -- Summary: I/O read/positioning problem Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
[Bug target/31325] gcj support for ARM EABI
--- Comment #22 from aph at gcc dot gnu dot org 2007-09-04 19:14 --- Done. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #4 from dorit at gcc dot gnu dot org 2007-09-04 19:14 --- (by the way, fast-math should not be required here, but that's a different bug... will fix that soonish) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-04 19:11 ---
I'm testing this patch:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 128037)
--- tree-vect-transform.c (working copy)
*** vect_create_epilog_for_reduction (tree v
*** 1964,1969
--- 1964,1971
tree operation = GIMPLE_STMT_OPERAND (stmt, 1);
bool nested_in_vect_loop = false;
int op_type;
+ VEC(tree,heap) *phis = NULL;
+ int i;
if (nested_in_vect_loop_p (loop, stmt))
{
*** vect_finalize_reduction:
*** 2260,2270
epilog_stmt = build_gimple_modify_stmt (new_dest, expr);
new_temp = make_ssa_name (new_dest, epilog_stmt);
GIMPLE_STMT_OPERAND (epilog_stmt, 0) = new_temp;
- #if 0
- bsi_insert_after (&exit_bsi, epilog_stmt, BSI_NEW_STMT);
- #else
bsi_insert_before (&exit_bsi, epilog_stmt, BSI_SAME_STMT);
- #endif
}
--- 2262,2268
*** vect_finalize_reduction:
*** 2274,2318
Find the loop-closed-use at the loop exit of the original scalar result.
(The reduction result is expected to have two immediate uses - one at
the
latch block, and one at the loop exit). */
! exit_phi = NULL;
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, scalar_dest)
{
if (!flow_bb_inside_loop_p (loop, bb_for_stmt (USE_STMT (use_p
{
exit_phi = USE_STMT (use_p);
! break;
}
}
/* We expect to have found an exit_phi because of loop-closed-ssa form. */
! gcc_assert (exit_phi);
! if (nested_in_vect_loop)
{
! stmt_vec_info stmt_vinfo = vinfo_for_stmt (exit_phi);
! /* FORNOW. Currently not supporting the case that an inner-loop
reduction
!is not used in the outer-loop (but only outside the outer-loop). */
! gcc_assert (STMT_VINFO_RELEVANT_P (stmt_vinfo)
! && !STMT_VINFO_LIVE_P (stmt_vinfo));
!
! epilog_stmt = adjustment_def ? epilog_stmt : new_phi;
! STMT_VINFO_VEC_STMT (stmt_vinfo) = epilog_stmt;
! set_stmt_info (get_stmt_ann (epilog_stmt),
! new_stmt_vec_info (epilog_stmt, loop_vinfo));
! if (vect_print_dump_info (REPORT_DETAILS))
! {
! fprintf (vect_dump, "vector of partial results after inner-loop:");
! print_generic_expr (vect_dump, epilog_stmt, TDF_SLIM);
! }
! return;
}
-
- /* Replace the uses: */
- orig_name = PHI_RESULT (exit_phi);
- FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, orig_name)
- FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
- SET_USE (use_p, new_temp);
}
--- 2272,2313
Find the loop-closed-use at the loop exit of the original scalar result.
(The reduction result is expected to have two immediate uses - one at
the
latch block, and one at the loop exit). */
! phis = VEC_alloc (tree, heap, 10);
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, scalar_dest)
{
if (!flow_bb_inside_loop_p (loop, bb_for_stmt (USE_STMT (use_p
{
exit_phi = USE_STMT (use_p);
! VEC_quick_push (tree, phis, exit_phi);
}
}
/* We expect to have found an exit_phi because of loop-closed-ssa form. */
! gcc_assert (!VEC_empty (tree, phis));
! for (i = 0; VEC_iterate (tree, phis, i, exit_phi); i++)
{
! if (nested_in_vect_loop)
! {
! stmt_vec_info stmt_vinfo = vinfo_for_stmt (exit_phi);
! /* FORNOW. Currently not supporting the case that an inner-loop
reduction
!is not used in the outer-loop (but only outside the outer-loop).
*/
! gcc_assert (STMT_VINFO_RELEVANT_P (stmt_vinfo)
! && !STMT_VINFO_LIVE_P (stmt_vinfo));
!
! epilog_stmt = adjustment_def ? epilog_stmt : new_phi;
! STMT_VINFO_VEC_STMT (stmt_vinfo) = epilog_stmt;
! set_stmt_info (get_stmt_ann (epilog_stmt),
! new_stmt_vec_info (epilog_stmt, loop_vinfo));
! continue;
! }
! /* Replace the uses: */
! orig_name = PHI_RESULT (exit_phi);
! FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, orig_name)
! FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
! SET_USE (use_p, new_temp);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #9 from dje at gcc dot gnu dot org 2007-09-04 19:11 --- By the way, nint_2.f90 also fails at -O0 on AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #5 from pinskia at gmail dot com 2007-09-04 19:08 --- Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE statements On 4 Sep 2007 19:03:39 -, ubizjak at gmail dot com <[EMAIL PROTECTED]> wrote: > and c never generates RECORD_TYPEs Yes it does. Structs in C are done as RECORD_TYPEs. This code is just plainly wrong really. fold_convert should not handle RECORD_TYPEs. And if does, it is not going to help with optimizations anyways. The Fortran front-end has to better keep track of modules and types inside modules to get this correct. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #4 from ubizjak at gmail dot com 2007-09-04 19:03 --- (In reply to comment #3) > Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type), > add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both > RECORD_TYPEs have the same size, and that their fields correspond one-to-one, > and then create a VIEW_CONVERT_EXPR? Do you think it would be worth having or > would that hurt the middle-end in any way? This is not exactly the part of gcc I'm familiar with (and c never generates RECORD_TYPEs), but I think that this problem should be fixed in fortran/trans-expr.c. At least according to the comment above fold_convert(), this conversion should be handled in front-end convert function. The "patch" below (similar to your proposal, with minimal checking) "works" in the sense that the compilation doesn't break, and generated code doesn't create a black hole at runtime, but I have no idea if it is correct (fortran) transformation. Also, we will break here if sizes are not equal. Index: fold-const.c === --- fold-const.c(revision 128092) +++ fold-const.c(working copy) @@ -2616,6 +2616,10 @@ || TREE_CODE (orig) == VECTOR_TYPE); return fold_build1 (VIEW_CONVERT_EXPR, type, arg); +case RECORD_TYPE: + gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig))); + return fold_build1 (VIEW_CONVERT_EXPR, type, arg); + case VOID_TYPE: tem = fold_ignored_result (arg); if (TREE_CODE (tem) == GIMPLE_MODIFY_STMT) > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug c++/31411] [4.1/4.2/4.3 Regression] ICE in gimplify_expr with throw/special copy constructor with initializer with a deconstructor
--- Comment #8 from jason at gcc dot gnu dot org 2007-09-04 18:37 --- Subject: Bug 31411 Author: jason Date: Tue Sep 4 18:37:33 2007 New Revision: 128100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128100 Log: PR c++/31411 * except.c (initialize_handler_parm): Put a CLEANUP_POINT_EXPR inside the MUST_NOT_THROW_EXPR. Added: trunk/gcc/testsuite/g++.dg/eh/catch5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
[Bug fortran/33241] ICE with parameter string arrays
--- Comment #5 from pault at gcc dot gnu dot org 2007-09-04 18:17 --- A fix for this one is coming with that for PR31564 - within 48 hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-30 13:40:52 |2007-09-04 18:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
[Bug fortran/31564] Error: Type/rank mismatch in argument
--- Comment #7 from pault at gcc dot gnu dot org 2007-09-04 18:16 --- To my surprise, I have a fix for this one. I'll post it to the list in the next 48 hours. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-22 18:49:14 |2007-09-04 18:16:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31564
[Bug bootstrap/33100] [4.3 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #1 from ro at gcc dot gnu dot org 2007-09-04 18:10 --- Confirmed on i386-pc-solaris2.10. This is a mainline regression. A reghunt revealed that this patch 2007-08-06 H.J. Lu <[EMAIL PROTECTED]> Daniel Jacobowitz <[EMAIL PROTECTED]> PR target/31868 * config.gcc (x86_64-*-freebsd*): Add i386/t-crtstuff to tmake_file. (x86_64-*-netbsd*): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-kfreebsd*-gnu): Likewise. (x86_64-*-knetbsd*-gnu): Likewise. (i[34567]86-*-solaris2.1[0-9]*): Likewise. is the culprit: running elfdump on the amd64 crtend.o before and after the patch, I find (before): Unwind Section: .eh_frame CIE: [0x] length: 0x00 cieid: 0 version: 0 augstring: `' codealign: 0x0 dataalign: 0 retaddr: 0 vs. (after): Unwind Section: .eh_frame FDE: [0x] length: 0x00 cieptr: 0x18 initloc: 0x addrrange: 0x Auxiliary vals: CIE: [0x0004] length: 0x18 cieid: 0 version: 1 augstring: `zR' codealign: 0x1 dataalign: -8 retaddr: 16 So the linker seems to be right to complain about this. Rainer -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-04 18:10:17 date|| Summary|on bootstrap getting section|[4.3 regression] on |.eh_frame: bad cie version |bootstrap getting section |0: offset 0x0 |.eh_frame: bad cie version ||0: offset 0x0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #19 from aph at gcc dot gnu dot org 2007-09-04 18:00 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 18:00:31 2007
New Revision: 128098
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128098
Log:
2007-09-04 Andrew Haley <[EMAIL PROTECTED]>
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
2007-08-29 Andrew Haley <[EMAIL PROTECTED]>
* gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
Make sure we're not sibcalled.
(GET_CALLING_CLASS): Define for ARM EABI.
2007-08-22 Andrew Haley <[EMAIL PROTECTED]>
* configure.host (BACKTRACESPEC): Add arm*-linux*.
2007-08-22 Andrew Haley <[EMAIL PROTECTED]>
* configure.ac (LIBSTDCXXSPEC): New.
* configure.host: Add arm*-linux* to pthread test.
* configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
EABI.
* testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
-fexceptions for ARM EABI.
* testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
(libjava_invoke): Log the invocation.
2007-08-15 Andrew Haley <[EMAIL PROTECTED]>
* configure.ac (extra_ldflags): Define.
* Makefile.am: Use extra_ldflags for all executables.
2007-08-14 Andrew Haley <[EMAIL PROTECTED]>
* sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
_Unwind_GetRegionStart, and _Unwind_Backtrace.
2007-07-27 Andrew Haley <[EMAIL PROTECTED]>
* gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
ARM EABI.
* exception.cc (get_exception_header_from_ue): New.
(get_ttype_entry): ARM EABI version.
(PERSONALITY_FUNCTION): Add ARM EABI code.
* sysdep/arm/backtrace.h: New file.
* stacktrace.cc (_URC_NORMAL_STOP): New.
* configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
EABI.
* configure.host (BACKTRACESPEC): Add arm/backtrace.h.
Added:
trunk/libjava/sysdep/arm/backtrace.h
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/sysdep/arm/backtrace.h
Modified:
trunk/libjava/Makefile.am
trunk/libjava/Makefile.in
trunk/libjava/configure
trunk/libjava/configure.ac
trunk/libjava/configure.host
trunk/libjava/exception.cc
trunk/libjava/gcj/Makefile.in
trunk/libjava/gnu/classpath/natVMStackWalker.cc
trunk/libjava/include/Makefile.in
trunk/libjava/libgcj.spec.in
trunk/libjava/stacktrace.cc
trunk/libjava/testsuite/Makefile.in
trunk/libjava/testsuite/lib/libjava.exp
trunk/libjava/testsuite/libjava.jni/jni.exp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #18 from aph at gcc dot gnu dot org 2007-09-04 17:58 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 17:57:52 2007
New Revision: 128097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128097
Log:
2007-09-04 Andrew Haley <[EMAIL PROTECTED]>
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
2007-08-29 Andrew Haley <[EMAIL PROTECTED]>
* gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
Make sure we're not sibcalled.
(GET_CALLING_CLASS): Define for ARM EABI.
2007-08-22 Andrew Haley <[EMAIL PROTECTED]>
* configure.host (BACKTRACESPEC): Add arm*-linux*.
2007-08-22 Andrew Haley <[EMAIL PROTECTED]>
* configure.ac (LIBSTDCXXSPEC): New.
* configure.host: Add arm*-linux* to pthread test.
* configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
EABI.
* testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
-fexceptions for ARM EABI.
* testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
(libjava_invoke): Log the invocation.
2007-08-15 Andrew Haley <[EMAIL PROTECTED]>
* configure.ac (extra_ldflags): Define.
* Makefile.am: Use extra_ldflags for all executables.
2007-08-14 Andrew Haley <[EMAIL PROTECTED]>
* sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
_Unwind_GetRegionStart, and _Unwind_Backtrace.
2007-07-27 Andrew Haley <[EMAIL PROTECTED]>
* gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
ARM EABI.
* exception.cc (get_exception_header_from_ue): New.
(get_ttype_entry): ARM EABI version.
(PERSONALITY_FUNCTION): Add ARM EABI code.
* sysdep/arm/backtrace.h: New file.
* stacktrace.cc (_URC_NORMAL_STOP): New.
* configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
EABI.
* configure.host (BACKTRACESPEC): Add arm/backtrace.h.
Modified:
trunk/libjava/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #17 from aph at gcc dot gnu dot org 2007-09-04 17:55 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 17:54:56 2007
New Revision: 128094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128094
Log:
2007-09-04 Andrew Haley <[EMAIL PROTECTED]>
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
Added:
trunk/libjava/testsuite/libjava.lang/Foo.class
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/Foo.class
trunk/libjava/testsuite/libjava.lang/WalkerTest.jar
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.jar
trunk/libjava/testsuite/libjava.lang/WalkerTest.java
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.java
trunk/libjava/testsuite/libjava.lang/WalkerTest.out
- copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.out
Modified:
trunk/libjava/testsuite/libjava.lang/PR27908.jar
trunk/libjava/testsuite/libjava.lang/PR27908.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug c++/29018] empty enum accepted
--- Comment #9 from pcarlini at suse dot de 2007-09-04 17:53 --- Humm, no, anonymous enums are clearly legal, sorry about the stupid mistake. Still, it's not completely clear to me the discussion in 7.2/5 of empty enumerator-lists, evidently, we must assume those are illegal *only* when the enum is simultaneously anonymous (and the patch in Comment #2 is therefore incomplete, not completely wrong, sorry about the misunderstanding). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug c++/29018] empty enum accepted
--- Comment #8 from pcarlini at suse dot de 2007-09-04 17:47 ---
Hummm, with reference to the patch in Comment #9: I don't think 'enum { };' is
flagged in the standard as ill-formed because of the empty enumerator-list
(that possibility is explicitly discussed in 7.2/5), but because the enum
doesn't have a name. In other terms, the example is ill-formed for the very
same reason anonymous structs are a GNU extension. In yet other terms, it seems
to me we have got an anonymous enum extension, which probably we want to
diagnose when pedantic.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug bootstrap/33306] New: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B: ICE in convert_move, at expr.c:369
Bootstrapping current mainline as of 20070903 fails on alpha-dec-osf5.1b building the stage 1 libgcc: /vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/xgcc -B/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/ -B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem /vol/gcc/alpha-dec-osf5.1b/include -isystem /vol/gcc/alpha-dec-osf5.1b/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/vol/gcc/src/gcc-dist/libgcc -I/vol/gcc/src/gcc-dist/libgcc/. -I/vol/gcc/src/gcc-dist/libgcc/../gcc -I/vol/gcc/src/gcc-dist/libgcc/../include -DHAVE_CC_TLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c \ /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__powitf2': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:1742: internal compiler error: in convert_move, at expr.c:369 The same problem happens at -O, while -O0 is ok. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. -- Summary: [4.3 regression] Bootstrap failure on Tru64 UNIX V5.1B: ICE in convert_move, at expr.c:369 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33306
[Bug c++/29018] empty enum accepted
--- Comment #7 from pcarlini at suse dot de 2007-09-04 16:51 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29018
[Bug preprocessor/33305] New: We should warn about empty macro arguments
As noted in PR33304, empty macro arguments can cause problems for ISO C90 compilers (solaris cc) as well as for older gcc versions like 2.8.1. Therefore I'd like to see cpp warn about these constructs either with -pedantic in C90 more and/or its own flag. We should use this warning during bootstrap to keep the sources bootstrappable when using compilers that have this issue. We have to fix the existing cases before we do that though. -- Summary: We should warn about empty macro arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org BugsThisDependsOn: 33304 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug bootstrap/33304] New: Bootstrap failure on solaris2 using cc due to empty macro arguments
I'm getting bootstrap failure with mainline on sparc-sun-solaris2.10 using cc for stage1. The failure occurs due to empty macro arguments. They occur in two places, one of which I've posted a patch for: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01131.html The second occurance is in c-common.c on line 2249 where it says: C_COMMON_FIXED_TYPES (, fract); Other instances occur below that in the same file. In another thread, I fixed an empty macro argument problem encountered when using gcc-2.8.1 for stage1 here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01119.html According to Joseph later in that thread, empty macro arguments are undefined in ISO C90. Since we claim to only require ISO C90 to bootstrap, and because we want to ensure older versions of GCC continue to be usable to bootstrap, IMHO we should not allow empty macro arguments in the sources. -- Summary: Bootstrap failure on solaris2 using cc due to empty macro arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC host triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33304
[Bug fortran/33303] Document __GFORTRAN__
-- 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 |2007-09-04 16:02:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33303
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #20 from jason at gcc dot gnu dot org 2007-09-04 15:43 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 15:43:00 2007 New Revision: 128090 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128090 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/mem-partial1.C - copied unchanged from r128077, trunk/gcc/testsuite/g++.dg/template/mem-partial1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/mem-partial2.C - copied unchanged from r128077, trunk/gcc/testsuite/g++.dg/template/mem-partial2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-04 15:25 --- > integer array(5), i1, i2 > print *, size(array,(/i1,i2/)) 13.7.112 SIZE (ARRAY [, DIM, KIND]) ARRAY may be of any type. It shall not be scalar. DIM (optional) shall be scalar and of type integer KIND (optional) shall be a scalar integer initialization expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug fortran/33303] New: Document __GFORTRAN__
I think __GFORTRAN__ is undocumented - at least I could not find any .texi where it is documented. I think it should be documented in doc/cpp.texi, possibly also in fortran/*texi. -- Summary: Document __GFORTRAN__ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation 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=33303
[Bug c++/14622] type mismatch in explicit template instantiation not detected
--- Comment #5 from pcarlini at suse dot de 2007-09-04 15:01 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14622
[Bug c++/14178] doc bug: -fabi-version=2 is now default (not 1)
--- Comment #12 from pcarlini at suse dot de 2007-09-04 14:28 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14178
[Bug c++/14178] doc bug: -fabi-version=2 is now default (not 1)
--- Comment #11 from paolo at gcc dot gnu dot org 2007-09-04 14:27 --- Subject: Bug 14178 Author: paolo Date: Tue Sep 4 14:27:05 2007 New Revision: 128085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128085 Log: 2007-09-04 Emmanuel Thome <[EMAIL PROTECTED]> PR c++/14178 * common.opt: Mention ABI version 2 in comment. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14178
[Bug tree-optimization/33302] New: follow-up on bug 33291 dead-store not eliminated
This is a follow-up on bug 33291. It uses the same testcase (repeated here) but
with some additional optimization flags.
---
struct Clock {
void f();
void add(unsigned n) { a += n; }
int a;
};
struct CPU : Clock {
virtual ~CPU();
unsigned char readSlow();
void execute();
void delay() { add(2); }
unsigned char readFast() {
if (unsigned char* p = ptrs[addr >> 8]) {
// fast-path
delay();
delay();
return p[addr & 255];
} else {
// slow-path
return readSlow();
}
}
typedef void (CPU::*FuncPtr)();
static FuncPtr tab[256];
unsigned char* ptrs[256];
unsigned addr;
};
void CPU::execute() {
f();
while (true) {
unsigned char b = readFast();
delay();
(this->*tab[b])();
}
}
When compiled with SVN revision 128074 on a linux x86_64 machine:
> g++ -O3 -fforce-addr -ftracer -S CPU.ii
> cat CPU.s
...
movl(%rbx), %eax
leal4(%rax), %edx
addl$6, %eax
movl%edx, (%rbx) dead store
movzbl (%r12), %edx
movzbl (%rcx,%rdx), %edx
movl%eax, (%rbx)
...
--
Summary: follow-up on bug 33291 dead-store not eliminated
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33302
[Bug c++/31419] [4.1/4.2/4.3 regression] template user defined conversion operator instantiated for conversion to self
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-09 15:35:38 |2007-09-04 14:06:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #16 from aph at gcc dot gnu dot org 2007-09-04 14:00 ---
Subject: Bug 27908
Author: aph
Date: Tue Sep 4 14:00:06 2007
New Revision: 128082
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128082
Log:
2007-09-04 Andrew Haley <[EMAIL PROTECTED]>
PR java/27908
* testsuite/libjava.lang/PR27908.java
({run1,run2,run3}.isRunning): New Method.
(main): Fix race condition.
Modified:
branches/gcj/gcj-eabi-branch/libjava/ChangeLog
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.jar
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2007-09-04
13:04 ---
Quoting spread_generic.c:
145 for (n = 0; n < ncopies; n++)
146{
147 memcpy (dest, sptr, size);
148 dest += rdelta;
149}
The C 99 Standard has the following to say about the mem* functions (7.21.2.1
ff):
Where an argument declared as size_t n specifies the length of the array for a
function, n can have the value zero on a call to that function. Unless
explicitly stated otherwise in the description of a particular function in this
subclause, pointer arguments on such a call shall still have valid values, as
described in 7.1.4.
So "size" can be zero, *but the the pointer arguments on such a call shall
still have valid values.*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug tree-optimization/33301] New: wrong vectorization factor due to an invariant type-promotion in the loop
This testcase: gfortran.dg/g77/990115-1.f
ICEs when compiled with vectorization enabled:
gfortran 990115-1.f -O -pedantic-errors -S -O2 -ftree-vectorize -msse2
-fdump-tree-vect-details -g -o 990115-1.s
990115-1.f: In function 'zgelsx':^M
990115-1.f:3: internal compiler error: in vectorizable_type_promotion, at
tree-vect-transform.c:3959
This is because of this assumption in
tree-vect-analyze.c:vect_determine_vectorization_factor:
"
/* We set the vectype according to the type of the result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
However, in such a case, that a variable of this datatype
does not appear in the lhs anywhere in the loop, it shouldn't
affect the vectorization factor. */
"
It so happens that we can have a situation in which the smallest type in the
loop nevers appears in the lhs: in the above testcase we have an invariant
type-promotion stmts that is not taken out of the loop before vectorization:
:
# i_1 = PHI <1(3), i_17(5)>
D.1363_9 = (real8) s2_8(D);//<--- HERE
D.1361_11 = ismax_5(D) + -2;
D.1362_12 = D.1361_11 + i_1;
CR.22_27 = REALPART_EXPR <(*work_13(D))[D.1362_12]>;
CI.23_28 = IMAGPART_EXPR <(*work_13(D))[D.1362_12]>;
CR.24_29 = D.1363_9 * CR.22_27;
CI.25_30 = D.1363_9 * CI.23_28;
REALPART_EXPR <(*work_13(D))[D.1362_12]> = CR.24_29;
IMAGPART_EXPR <(*work_13(D))[D.1362_12]> = CI.25_30;
i_17 = i_1 + 1;
if (i_1 == D.1355_3)
goto ;
else
goto ;
(Indeed when compiling also with --param lim-expensive=1, the invariant stmt is
taken out of the loop and the testcase passes).
I am testing the following patch:
Index: tree-vect-analyze.c
===
*** tree-vect-analyze.c (revision 128037)
--- tree-vect-analyze.c (working copy)
*** vect_determine_vectorization_factor (loo
*** 216,236
}
else
{
gcc_assert (! STMT_VINFO_DATA_REF (stmt_info)
&& !is_pattern_stmt_p (stmt_info));
! /* We set the vectype according to the type of the result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the
smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
!However, in such a case, that a variable of this datatype
!does not appear in the lhs anywhere in the loop, it shouldn't
!affect the vectorization factor. */
scalar_type = TREE_TYPE (GIMPLE_STMT_OPERAND (stmt, 0));
if (vect_print_dump_info (REPORT_DETAILS))
{
fprintf (vect_dump, "get vectype for scalar type: ");
--- 216,253
}
else
{
+ tree operation;
+
gcc_assert (! STMT_VINFO_DATA_REF (stmt_info)
&& !is_pattern_stmt_p (stmt_info));
! /* We generally set the vectype according to the type of the
!result (lhs).
For stmts whose result-type is different than the type of the
arguments (e.g. demotion, promotion), vectype will be reset
appropriately (later). Note that we have to visit the
smallest
datatype in this function, because that determines the VF.
If the smallest datatype in the loop is present only as the
rhs of a promotion operation - we'd miss it here.
!Such a case, where a variable of this datatype does not appear
!in the lhs anywhere in the loop, can only occur if it's an
!invariant: e.g.: 'int_x = (int) short_inv', which we'd expect
!to have been optimized away by invariant motion. However, we
!cannot rely on invariant motion to always take invariants out
!of the loop, and so in the case of promotion we also have to
!check the rhs. */
scalar_type = TREE_TYPE (GIMPLE_STMT_OPERAND (stmt, 0));
+ operation = GIMPLE_STMT_OPERAND (stmt, 1);
+ if (TREE_CODE (operation) == NOP_EXPR
+ || TREE_CODE (operation) == CONVERT_EXPR
+ || TREE_CODE (operation) == WIDEN_MULT_EXPR)
+ {
+ tree rhs_type = TREE_TYPE (TREE_OPERAND
[Bug c++/31411] [4.1/4.2/4.3 Regression] ICE in gimplify_expr with throw/special copy constructor with initializer with a deconstructor
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 15:08:14 |2007-09-04 12:39:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31411
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
-- 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 |2007-09-04 12:34:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-04 12:34 --- (In reply to comment #2) > (1) at least it should go the "enhancement" with the addition of " This check > can be disabled with the option -fno-range-check" We can do that, indeed. Reopening and marking enhancement. > (2) I think the two cases are totally different: > as soon as the compiler knows INF/NAN (and gfortran does), I think > nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should > not throw even a warning (even with -std=xx -pedantic). I think the standard is very clear on that. Quoting F2003 13.7: "A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate." Unless we have IEEE_ARITHMETIC, we should stick to an error. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #19 from jason at gcc dot gnu dot org 2007-09-04 12:28 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 12:27:38 2007 New Revision: 128077 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128077 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Added: trunk/gcc/testsuite/g++.dg/template/mem-partial1.C trunk/gcc/testsuite/g++.dg/template/mem-partial2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c++/14032] Specialization of inner template using outer template argument doesn't work
--- Comment #18 from jason at gcc dot gnu dot org 2007-09-04 12:27 --- Subject: Bug 14032 Author: jason Date: Tue Sep 4 12:27:21 2007 New Revision: 128076 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128076 Log: PR c++/14032 * pt.c (most_specialized_class): Substitute outer template arguments into the arguments of a member template partial specialization. (strip_innermost_template_args): New fn. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition
--- Comment #11 from eres at il dot ibm dot com 2007-09-04 12:18 --- The patch was committed to r128075. Revital -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-04 12:13 --- Yes please. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug tree-optimization/33291] [4.3 Regression] a+=2; a+=2 not simplified to a+=4; with -O3 (ok with gcc-4.2.1)
--- Comment #7 from wouter dot vermaelen at scarlet dot be 2007-09-04 12:11 --- Thanks for looking into this so quickly! I confirm the problem is solved for the reduced testcase. However in my original code the dead-store is not eliminated. Do you want me to file a separate bug report for that? mov(%rbx),%edx movzbl %cl,%edi lea0x3(%rdx),%r8d add$0x5,%edx mov%r8d,(%rbx) movzbl (%rsi,%rdi,1),%eax mov%edx,(%rbx) -- wouter dot vermaelen at scarlet dot be changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33291
[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error
--- Comment #2 from dominiq at lps dot ens dot fr 2007-09-04 12:05 --- I don't think the PR is invalid: (1) at least it should go the "enhancement" with the addition of " This check can be disabled with the option -fno-range-check" as in print *, huge(0), -2147483648 1 Error: Integer too big for its kind at (1). This check can be disabled with the option -fno-range-check (2) I think the two cases are totally different: huge(0)+1 cannot be represented in the integer model, thus the overflow; as soon as the compiler knows INF/NAN (and gfortran does), I think nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should not throw even a warning (even with -std=xx -pedantic). I don't want to start a flame war of this issue, but look at the number of mails, answers, noise, ..., generated by -2147483648 (note that I did not write -(2147483648)!-). -- dominiq at lps dot ens dot fr changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33296
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
-- dorit at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-04 11:44 --- (In reply to comment #1) > Confirmed. It looks like the vectorizer forgets to update the PHI node for > stmp_var: yes. I suspect I didn't expect at the time that there would be two loop-closed-ssa-form phi-nodes at the loop exit for s_3, so I probably update just one of them (s_10) and not the other (s_4). This is how it looks before vectorization: : # s_4 = PHI # s_10 = PHI D.1368_15 = *x_14(D); if (D.1368_15 < 0.0) goto ; else goto ; : s_16 = -s_10; : # s_1 = PHI return s_1; I'll prepare a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
