[Bug rtl-optimization/20800] [4.0 regression] cris-elf testsuite failure: gcc.c-torture/execute/931004-6.c -O3
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07 07:27 --- CRIS is not a primary target. Removing target milestone. -- What|Removed |Added Target Milestone|4.0.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20800
[Bug fortran/19269] transpose(reshape(...)) of character array segfaults.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 07:36 --- Subject: Bug 19269 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 07:36:12 Modified files: gcc/fortran: ChangeLog simplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.fortran-torture/execute: pr19269-1.f90 Log message: PR fortran/19269 * simplify.c (gfc_simplify_transpose): Set the result's typespec from the source, not the first element of the return value. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.536r2=1.537 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/simplify.c.diff?cvsroot=gccr1=1.30r2=1.31 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6021r2=1.6022 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/pr19269-1.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19269
[Bug java/20031] [4.0/4.1 regression] ICE on missing files
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07 07:45 --- Java bugs are not release-critical; removing target milestone. -- What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug target/11015] [PPC] -finstrument-functions and variable size with sizes 17 and -fPIC
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11015
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-07 09:00 --- I'll take care of it. Arno -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |charlet at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug middle-end/23522] [3.4/4.0/4.1 Regression] fold_widened_comparison bug
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-07 09:26 --- I agree with the analysis and the fix. Care to submit the patch to gcc-patches? Do you have a copyright assignment on file with the FSF? If not the patch may be simple enough to be accepted regardless of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23522
[Bug ada/22418] Ada produces mis-match (non compatible) types in MODIFY_EXPR
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-07 09:59 --- Long-standing problem in Gigi, will be fixed by the next push from AdaCore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22418
[Bug target/20529] m6811-elf-g++ ICE
--- Additional Comments From goweol at gmail dot com 2005-09-07 10:20 --- After reported this bug, I built several m6811-elf-gcc compiler. Those are 20050318, 20050426, 20050516, and 20050907 version. At this time, 20050318 and 20050426 generates ICE. But 20050516 and 20050907 version compiles it fine. So, you might want to close this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20529
[Bug libstdc++/23632] std::vectorbool in combination with debug mode fails to compile code
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:23 --- Not a regression, in any sense. Given that, and the almost-deprecated status of vectorbool, better not touching this for the current release branch. Fixed for 4.1.0, anyway. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.2 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23632
[Bug fortran/21730] Character length incorrect.
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 10:37 --- Is this still a problem? The other two testcases seem to work now. -- What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21730
[Bug fortran/21825] [4.0/4.1 Regression] 2D array initialization with reshape
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 10:40 --- Fixed by the partial patch for 19269 -- What|Removed |Added OtherBugsDependingO||19269 nThis|| Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
-- Bug 19276 depends on bug 21825, which changed state. Bug 21825 Summary: [4.0/4.1 Regression] 2D array initialization with reshape http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:42 --- Not a but, this behavior is intended and correct. According to the Standard (Table 57), the stdio equivalent for hex formatting will be exactly %x (or %X). Then try printf(%x, -1) on your machine. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/22518] ICE in gfc_conv_function_call for character function with LEN=length(arg)
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 10:45 --- Fixed by the same patch as 15326. -- What|Removed |Added BugsThisDependsOn||15326 AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-17 15:47:49 |2005-09-07 10:45:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22518
[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:55 --- Fixed for 4.1.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13943
[Bug target/23747] ICE with -O2, -O3 execute/builtins/memcpy-chk.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 11:58 --- Subject: Bug 23747 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 11:57:47 Modified files: gcc: ChangeLog gcc/config/m32r: m32r.md Log message: PR target/23747 * config/m32r.md (movmemsi_internal): Canonicalize order of operands in PLUS component of template. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9914r2=2.9915 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/m32r/m32r.md.diff?cvsroot=gccr1=1.56r2=1.57 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23747
[Bug target/23747] ICE with -O2, -O3 execute/builtins/memcpy-chk.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 12:05 --- Subject: Bug 23747 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 12:04:42 Modified files: gcc: ChangeLog gcc/config/m32r: m32r.md Log message: PR target/23747 * config/m32r.md (movmemsi_internal): Canonicalize order of operands in PLUS component of template. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.417r2=2.7592.2.418 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/m32r/m32r.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.50.10.1r2=1.50.10.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23747
[Bug libgcj/23761] New: java.library.path doesn't affect module loading path
Setting java.library.path on the gij command line should set the module loader
path to the given argument. Currently an attempt is made to do this in
natSystemProperties.cc:
// If java.library.path is set, tell libltdl so we search the new
// directories as well. FIXME: does this work properly on Windows?
::java::lang::String *path =
newprops-getProperty(JvNewStringLatin1(java.library.path));
if (path)
{
char *val = (char *) _Jv_Malloc (JvGetStringUTFLength (path) + 1);
jsize total = JvGetStringUTFRegion (path, 0, path-length(), val);
val[total] = '\0';
_Jv_SetDLLSearchPath (val);
_Jv_Free (val);
}
_Jv_SetDLLSearchPath in turn calls lt_dlsetsearchpath but this call does nothing
since lt_dlinit has not been called at this point in gij startup.
--
Summary: java.library.path doesn't affect module loading path
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fitzsim at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23761
[Bug libgcj/23762] New: java.library.path should default to value of environment variable specified by LTDL_SHLIBPATH_VAR
If java.library.path was not specified on the command line its value should default to the contents of LD_LIBRARY_PATH on GNU/Linux systems or LTDL_SHLIBPATH_VAR generally. -- Summary: java.library.path should default to value of environment variable specified by LTDL_SHLIBPATH_VAR Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23762
[Bug libgcj/21741] Need configure option to set java.library.path
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 12:36 --- Filed two new bugs for the remaining java.library.path issues: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23761 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23762 I'm closing this bug. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
[Bug libgcj/23763] New: Runtime.getRuntime().exec() signalling
Showcase: compile exectest.c, run test.java calling 'exectest' Runtime.exec() seems to pass down some strange signal configuration to child processes in GCC =4.0.0. When run from test.java the exectest.c parent process does never get CHLD signals - they seem to get blocked (as I've seen the rtsig-queue growing each time test.java was run). GCC 3.3.3 does not have this problem. -- Summary: Runtime.getRuntime().exec() signalling Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aeby at graeff dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs 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=23763
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:17 --- Created an attachment (id=9686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9686action=view) Execs exectest and demonstrates how it hangs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug libgcj/23763] Runtime.getRuntime().exec() signalling
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:18 --- Created an attachment (id=9687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9687action=view) Sample program that hangs when executed via Runtime.exec() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
[Bug target/11015] [3.4 only] -finstrument-functions and dynamic stack allocation
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07 13:20 --- This is not a problem with dynamic stack allocation, but rather with the instrumentation code. The following diagram is supposed to show what the V4 stack layout looks like just after the function prologue, then a little later after some dynamic space has been allocated (eg. alloca or dynamically sized variables). The thing to note is that the old 8 byte stack header (consisting of the back chain and lr save space) before dynamic allocation becomes part of the new dynamic area, and a new stack header is just below. The old stack header thus can be overwritten, and this is what happens for certains sizes of dynamic vars. Missing this fact is no doubt why comment #2 incorrectly claims that not enough space is allocated. |||| | lr save|| lr save| |||| | back chain || back chain | ||- ||- | reg save, | | | reg save, | | | local vars | | | local vars | | | | | etc. | | | etc. | | 8|| | || | || | || | 4|| | | dynamic| | || | | var| | 0| back chain |--- | space | | FP,SP-||FP-|| | || | || | 8|| | || | 4|| | || | 0| back chain |--- SP-|| The error is that the instrumentation code on function exit tries to access the old stack header via FP. gcc-4.0 and gcc-4.1 avoid this problem by calling the instrumentation function after the dynamic space has been deallocated. I should note that gcc typically allocates too much dynamic space (to allow for a non-aligned initial stack pointer, which doesn't happen for ppc) and this is why most sizes of dynamic variables don't cause a problem. -- What|Removed |Added AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu |dot au |dot org Status|ASSIGNED|NEW Known to work||4.0.2 4.1.0 Summary|[PPC] -finstrument-functions|[3.4 only] -finstrument- |and variable size with sizes|functions and dynamic stack | 17 and -fPIC |allocation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11015
[Bug target/23747] ICE with -O2, -O3 execute/builtins/memcpy-chk.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 13:23 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23747
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-07 13:36 --- Subject: Re: CCP not fully propagating constants On Wed, 2005-09-07 at 04:19 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 04:19 --- (In reply to comment #3) And then we hit an assert if we change evaluate_stmt to be always call fold_ccp. The assert is in set_lattice_value, when we are changing from VARRYING to CONSTANT which should be a valid transition. Only if the VARRYING is the default state. Before the TCB, this was allowed: /* VARYING - CONSTANT is an invalid state transition, except for objects which start off in a VARYING state. */ VARYING-CONSTANT should actually never happen, regardless of what the comment says. We shouldn't set it to VARYING in the first place if we think it has a chance of becoming CONSTANT. So i imagine get_default_value or whatever needs to be more foregiving :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug fortran/19269] transpose(reshape(...)) of character array segfaults.
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 13:43 --- It's not clear who's on the hook to the fix the transpose() call. I'll unassign myself in the meantime. -- What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org AssignedTo|rsandifo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19269
[Bug middle-end/23711] [4.1 regression] [s390] bootstrap error in libjava (ICE in fixup_eh_region_note)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 14:03 --- Fixed by: 2005-09-07 Andreas Krebbel [EMAIL PROTECTED] * reload1.c (fixup_eh_region_note): Remove assertion. (fixup_abnormal_edges): Reverted removal of call to find_many_sub_basic_blocks made on 2005-08-31. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23711
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug libgcj/6181] Mauve Introspector.jdk11: getBeanInfo fail for AWT classes
-- What|Removed |Added Target Milestone|--- |3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6181
[Bug java/5942] tree check failure when compiling Classpath with strictfp StrictMath class
-- What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5942
[Bug java/2956] gcj does not terminate on invalid class definition
-- What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2956
[Bug java/1392] Using .class in super class of outer class and in inner class fails
-- What|Removed |Added Target Milestone|--- |3.0.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1392
[Bug target/23746] m32c.h has a typo
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23746
[Bug ada/23565] [4.1 Regression] ACATS FAIL c32001e inccorect array bounds
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23565
[Bug java/1391] ICE on bogus this.OuterClass.method() construct
-- What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1391
[Bug target/21255] %R and %S are not safe to use from asms
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21255
[Bug libfortran/19481] libgfortran doesn't build -- configure doesn't handle cabs() well
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
[Bug target/23721] [4.1 Regression] pt.c:9462: ICE: in change_address_1, at emit-rtl.c:1791
-- What|Removed |Added Keywords||build, ice-on-valid-code Summary|pt.c:9462: ICE: in |[4.1 Regression] pt.c:9462: |change_address_1, at emit- |ICE: in change_address_1, at |rtl.c:1791 |emit-rtl.c:1791 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23721
[Bug fortran/23661] 'print fmt' is unclassifiable statement in gfortran
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23661
[Bug rtl-optimization/23561] nonoverlapping_memrefs_p returns true even for overlapping memory references
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23561
[Bug testsuite/23607] gcc.target/i386/pr23575.c fails on x86_64
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
[Bug tree-optimization/23475] Frequences are not updated for empty loop removal
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23475
[Bug c/18382] define __pic__ and/or __PIC__ in c-cppbuiltins.c instead of scattershot in target config
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-09-07 14:18 --- Updated patch for mainline here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00302.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2004- |patches/2005- |04/msg00168.html|09/msg00302.html Status|NEW |ASSIGNED Last reconfirmed|2005-08-24 19:06:19 |2005-09-07 14:18:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18382
[Bug rtl-optimization/12535] Attempt to delete prologue/epilogue insn
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
14:39 ---
Simplified testcase. This bug is probably a WONTFIX.
int bar (int *);
int foo (void)
{
int x;
__builtin_memset (x, 0, 32);
return bar (x);
}
--
What|Removed |Added
Known to fail||3.4.5 4.0.2 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12535
[Bug tree-optimization/22555] array in struct disables salias subvars for other fields
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 15:25 --- Subject: Bug 22555 CVSROOT:/cvs/gcc Module name:gcc Branch: improved-aliasing-branch Changes by: [EMAIL PROTECTED] 2005-09-07 15:25:13 Modified files: gcc: tree-dfa.c tree-ssa-alias.c tree-ssa-loop-ivopts.c tree-ssa-loop.c tree-ssa-operands.c tree-ssa-structalias.c Added files: gcc: ChangeLog.iab gcc/testsuite : ChangeLog.iab gcc/testsuite/gcc.dg/tree-ssa: alias-3.c Log message: 2005-09-07 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/22555 * tree-dfa.c (okay_component_ref_for_subvars): Do not give up, if one structure field is an array. * tree-ssa-alias.c (create_overlap_variables_for): Likewise. * tree-ssa-structalias.c (create_variable_info_for): Likewise. (get_constraint_for_component_ref): Do not assert we can not only be accessing padding if we deal with an ARRAY_REF. * tree-ssa-loop-ivopts.c (rewrite_use): Mark new vars in stmt for renaming. * tree-ssa-loop.c (pass_iv_optimize): Schedule TODO_update_ssa. * tree-ssa-operands.c (get_expr_operands): Continue scanning operands even if we found a subvar, but ignore VOPs in this case. * gcc.dg/tree-ssa/alias-3.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.iab.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-dfa.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.63r2=2.63.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.109r2=2.109.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.87r2=2.87.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.33.6.1r2=2.33.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.100r2=2.100.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-structalias.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=2.27r2=2.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.iab.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/alias-3.c.diff?cvsroot=gcconly_with_tag=improved-aliasing-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22555
[Bug c++/23764] New: Implicit conversion to a reference for an object broken
Trying to compile the following code on a FreeBSD 5.4 machine, using GCC
4.0.1
# 1 Test.cpp
# 0 built-in
# 1 command line
# 1 Test.cpp
class OutStream
{
public:
OutStream();
};
inline OutStream operator( OutStream output, const int value )
{
return output;
}
class Client
{
public:
OutStream send()
{
return OutStream();
}
};
int main(int argc,char **argv)
{
Client myclient;
int x = 32;
int y = 64;
myclient.send() x y;
return 0;
}
Produces the following output...
Using built-in specs.
Target: i386-portbld-freebsd5.4
Configured with: ./..//gcc-4.1-20050730/configure --disable-nls --with-system-
zlib --with-libiconv-prefix=/usr/local --program-suffix=41 --
libdir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0 --with-gxx-include-
dir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++/ --disable-
shared --disable-rpath --prefix=/usr/local i386-portbld-freebsd5.4
Thread model: posix
gcc version 4.1.0 20050730 (experimental)
/usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.1.0/cc1plus -E -quiet -v
Test.cpp -fpch-preprocess -o Test.ii
ignoring nonexistent directory /usr/local/lib/gcc/i386-portbld-
freebsd5.4/4.1.0/gcc/i386-portbld-freebsd5.4/4.1.0/../../../../i386-portbld-
freebsd5.4/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++/
/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++//i386-portbld-
freebsd5.4
/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++//backward
/usr/local/include
/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/gcc/i386-portbld-
freebsd5.4/4.1.0/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.1.0/cc1plus -fpreprocessed
Test.ii -quiet -dumpbase Test.cpp -auxbase Test -version -o Test.s
GNU C++ version 4.1.0 20050730 (experimental) (i386-portbld-freebsd5.4)
compiled by GNU C version 4.1.0 20050730 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c62afa56bfea22d68bd8bf2d1f862a27
Test.cpp: In function 'int main(int, char**)':
Test.cpp:33: error: no match for 'operator' in 'myclient. Client::send()
x'
Test.cpp:11: note: candidates are: OutStream operator(OutStream, const
int)
--
Summary: Implicit conversion to a reference for an object broken
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rlyle at ritual dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23764
[Bug awt/21598] rendering problem with button text
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 15:48 --- I filed a bug against GTK: http://bugzilla.gnome.org/show_bug.cgi?id=315462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
[Bug c++/23764] Implicit conversion to a reference for an object broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
15:49 ---
Not a bug as you cannot bind a rvalue to the reference type.
Basicially what you have is:
int g(void);
void h(int);
void j(void)
{
h(g());
}
And that is invalid. You can bind a rvalue to a const reference type though.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23764
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 15:59 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-13 11:47:53 |2005-09-07 15:59:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/23765] New: segfault with syntactically wrong common declaration
[EMAIL PROTECTED]:~/src/tests cat pr16404.f90 REAL, TARGET :: B(2,2) common x/b/ B = 1. END [EMAIL PROTECTED]:~/src/tests ../gcc/build/gcc/f951 pr16404.f90 MAIN__ pr16404.f90:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:~/src/tests The segfault happens when the common block is being translated, but the code should have been rejected much earlier. -- Summary: segfault with syntactically wrong common declaration Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-07 16:03 --- The ANSI definition for %x (or %X) only covers unsigned integers. Surely then doing hex formatting on a signed integer would at the very least be undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/21143] cross-built gfortran installed as gfortran
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07 16:07 --- Can someone ping this patch on the gcc-patches ml? -- What|Removed |Added Last reconfirmed|2005-04-21 16:29:45 |2005-09-07 16:07:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 16:07 --- Confirmed, backtrace: #0 0x080a2406 in translate_common (common=0x96d29b8, var_list=Variable var_list is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:879 #1 0x0808ed05 in gfc_traverse_symtree (st=0x96d2998, func=0x80a25d0 named_common) at / home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/symbol.c:2295 #2 0x080a2534 in gfc_trans_common (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans-common.c:956 #3 0x080a7638 in gfc_generate_function_code (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/ gcc/src/gcc/fortran/trans-decl.c:2355 #4 0x08097a64 in gfc_generate_code (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans.c:683 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-07 16:07:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-07 16:09 --- (In reply to comment #16) Since number 2 is already reported, we only have 3 and 6 left: I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16404
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 16:17 --- Reduced testcase: common /b/ end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:28 --- (In reply to comment #7) The ANSI definition for %x (or %X) only covers unsigned integers. Surely then doing hex formatting on a signed integer would at the very least be undefined behavior. Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is not very precise, because, strictly speaking, the C Standard speaks only about unsigned int and the C++ Standard mandates %x for many different types (see 22.2.2.2.2/Stage1): then the user is allowed to invoke undefined behavior if he uses hex together with anything != unsigned int, that is, basically, *always* because unsigned int is not among the types over which do_put is overloaded! I consider this a defect of the C++ Standard and will take care of reporting it to the LWG Commitee. Thanks for pointing it out! As long as libstdc++-v3 is concerned, what we are doing in such circumstances, is implementing a kind of behavior, which is the one usually implemented by printf. This is good, in my opinion, because consistent with printf, thus very useful when C++ and C code interoperate. You are right that in principle libstdc++-v3 could well crash and remain conforming ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 16:30 --- Subject: Bug 23358 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 16:30:38 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_construct.h Log message: 2005-09-07 Thomas Kho [EMAIL PROTECTED] PR libstdc++/23358 * include/bits/stl_construct.h (_Destroy(_ForwardIterator, _ForwardIterator, allocator_Tp)): Removed unused template parameter. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.78r2=1.2917.2.79 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_construct.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.20r2=1.20.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:32 --- Fixed for 4.0.2 too. -- What|Removed |Added Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:51 --- (In reply to comment #8) Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is not very precise, because, strictly speaking, the C Standard speaks only about unsigned int and the C++ Standard mandates %x for many different types (see 22.2.2.2.2/Stage1): then the user is allowed to invoke undefined behavior if he uses hex together with anything != unsigned int, that is, basically, *always* because unsigned int is not among the types over which do_put is overloaded! I consider this a defect of the C++ Standard and will take care of reporting it to the LWG Commitee. Thanks for pointing it out! Actually, the issue is less general and serious (i.e., restricted to the signedness issue, that allows the user to easily invoke undefined behavior from the underlying printf), because, anyway, according to Table 59, an 'l' will prefix the 'x' or 'X', in case of long or unsigned long. Sorry about the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 16:58 --- Hmm. I supposed I'd better check. Is the following code also valid: program main implicit none real, dimension (:), pointer :: x x = null() x = test () contains function test real, dimension (:), pointer :: test if (associated (x)) call abort allocate (test (10)) if (associated (x)) call abort end function test end program main I've not read anything in the standard that forbids it, but I'd appreciate it if more seasoned folks could comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:02 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-09/msg00089.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug c++/23767] New: std::vector iterator implementation wrong
The following code does not compile. According to the compiler,
't' is overloaded ambiguously.
#include vector
struct T {
typedef std::vectorint Vector;
typedef Vector::iterator iterator;
typedef Vector::const_iterator const_iterator;
int t( iterator f) { return *f; }
int t( const_iterator f) const { return *f; }
};
int main(int, char*[])
{
std::vectorint v;
T t;
T::const_iterator i = v.begin();
t.t(i);
return 0;
}
We've seen this on gcc 3.2.2., 3.4.3, 4.0.1. Basically, the
const_iterator matches both the iterator and the const_iterator at function
resolution time. This seems to stem from the implementation of iterator in
std::vector using __normal_iterator. There is a template copy constructor that
appears to allow this illegal conversion.
Error on: gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
--
test.cc: In function int main(int, char**):
test.cc:18: error: ISO C++ says that these are ambiguous, even though
the
worst conversion for the first is better than the worst conversion for
the
second:
test.cc:10: note: candidate 1: int
T::t(__gnu_cxx::__normal_iteratorconst
int*, std::vectorint, std::allocatorint ) const
test.cc:9: note: candidate 2: int
T::t(__gnu_cxx::__normal_iteratorint*,
std::vectorint, std::allocatorint )
--
Summary: std::vector iterator implementation wrong
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: afra at cs dot stanford dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:04 --- I don't have the standard at hand, but both the Intel and the Portland Group compiler accept this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug c++/23767] std::vector iterator implementation wrong
--- Additional Comments From afra at cs dot stanford dot edu 2005-09-07 17:04 --- Created an attachment (id=9688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9688action=view) complete program showing bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From richard at codesourcery dot com 2005-09-07 17:07 --- Subject: Re: Functions returning pointers with pointer argument tobi at gcc dot gnu dot org [EMAIL PROTECTED] writes: I don't have the standard at hand, but both the Intel and the Portland Group compiler accept this. OK, thanks for checking! I'll work on the basis that it's valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added Known to fail||3.0.4 3.3.3 3.4.0 4.0.0 Known to work||2.95.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
-- What|Removed |Added Keywords|missed-optimization |diagnostic Last reconfirmed|2005-05-16 02:30:28 |2005-09-07 17:43:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416
[Bug target/20010] *arm_extendqisi appears to never be matched
--- Additional Comments From nico at cam dot org 2005-09-07 18:24 --- I just tested with HEAD today and the problem doesn't appear to be there any longer. Therefore gcc 4.1.0 should be OK. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20010
[Bug libgcj/23768] New: doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
The JCE spec for Cipher.doFinal states:
Upon finishing, this method resets this cipher object to the state it was in
when previously initialized via a call to init. That is, the object is reset and
available to encrypt or decrypt (depending on the operation mode that was
specified in the call to init) more data.
However, the various doFinal() methods of the Cipher class reset the cipher to
an uninitialized state. Subsequent calls to update() or doFinal() result in an
IllegalStateException.
The Cipher class contains the following in several doFinal methods:
...
if (state != ENCRYPT_MODE state != DECRYPT_MODE)
{
throw new IllegalStateException(neither encrypting nor decrypting);
}
state = INITIAL_STATE;
...
The state of the cipher should not be set to INITIAL_STATE after doFinal but
remain either in ENCRYPT_MODE or DECRYPT_MODE. All of the doFinal methods are
affected by this bug.
This is my first bug report here, so please let me know if more information is
needed such as an executable example. I'm also not sure (since I didn't see it
in the bug writing guidelines) whether I sould attach a patch for this bug.
The same problem also exists in the latest Classpath codebase.
--
Summary: doFinal() methods in javax.crypto.Cipher incorrectly
resetting cipher state
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qianzwang at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug tree-optimization/14705] [tree-ssa] more alias analysis needed!?
-- What|Removed |Added Keywords||alias Last reconfirmed|2005-07-04 21:36:12 |2005-09-07 18:35:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
[Bug classpath/23768] doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
-- What|Removed |Added Component|libgcj |classpath Product|gcc |classpath Version|4.0.1 |0.18 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug classpath/23768] doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
-- What|Removed |Added CC||bug-classpath at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-07 18:40 --- The behavior we are mimicing isn't printf()'s behavior. printf() doesn't print out hexadecimal signed integers as though they were unsigned integers. Intead, C's type coercion allows the signed integers to be interpreted as unsigned integers, and printf() then prints out the unsigned integers. While I understand the value of printf() compatibility, one of the key differentiators with iostreams is type safety, which is effectively broken with the current behavior. If we wanted to preserve printf() like behavior then 'cout hex some string' should print out the address of the string literal in hex, rather than the string literal's contents, ignoring the hex flag completely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug rtl-optimization/23324] [4.1 Regression] unsigned bitfield in struct not accessed correctly at -O2 and above
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-07 18:58 --- Looking into it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-08-11 12:22:54 |2005-09-07 18:58:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug target/16888] [3.4 Regression] ICE: in print_reg, at config/i386/i386.c:7254
-- What|Removed |Added Target Milestone|4.0.2 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:09 --- (In reply to comment #10) The behavior we are mimicing isn't printf()'s behavior. This statement of yours is by and large incorrect, in the face of the actual way the C++ Standard is formulated. Please read again 22.2.2.2.2/2! printf() doesn't print out hexadecimal signed integers as though they were unsigned integers. Intead, C's type coercion allows the signed integers to be interpreted as unsigned integers, and printf() then prints out the unsigned integers. This is not the case as far as C99 is concerned. According to the actual text of the C99 standard passing a signed type to printf(%x) triggers undefined behavior, see 7.19.6.1/9. And there are good reasons for this, pointed out moments ago by Martin Sebor on the LWG reflector (6.2.6.2/5 basically allows for negative integers that don't have a valid object representation in the corresponding unsigned signed type). On the LWG we are still discussing what the C89 says instead (C89 is rather different). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug c++/17256] [3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 19:11 --- Hmm, this works correctly with the C front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug c/23769] New: always inline short functions if inlining would be as small as non-inlined code
I noticed when compiling with gcc -std=c99 -Winline that this function
inline uint16_t f(uint16_t x) { return x; }
wasn't getting inlined. Inlining is also not done even when the function is
attributed with __attribute__ ((always_inline)), nor does inlining happen
when there no attributes at all. Maybe this function isn't getting inlined
because the compiler decided that it would involve in some sense too much
expansion in the caller.
Regardless of this particular case, I wonder if the following enhancement to
gcc would be worthwhile: always inline when it can be deduced that the code
with inlining would be no larger than the code without inlining, regardless of
the size of the caller in whatever representation is used at the time this
decision is being made.
For example, on many architectures, a call to a function that accepts an
argument and returns a value will use at least 3 instructions in the caller:
one to push the argument onto the stack, one to call the function, and one to
retrieve the return value from the function. So, if the function uses up to
three instructions to do its calculation, plus a return statement (with no
calculation in the return), then inlining will use no more instruction space
than not inlining. In these cases, inlining probably ought to be done so as to
create opportunities for further optimizations later, e.g., common
subexpression elimination. A more sophisticated determination could take into
account the number of arguments and other factors. This might be especially
helpful with C++ programs that have a lot of short methods.
At least, this is how it looks to me - if I am wrong, maybe someone could
educate me a bit or point me to some documentation where I can learn more about
how gcc's inlining works. If inlining is supposed to work this way already,
then I'll be happy to try to isolate the code further so that we have a small
fully compilable example.
I'm compiling with this:
gcc -o t.exe -DZCodeTest -g -DZAssert -D__GCC__ -std=c99 -O3 -pedantic -Werror -
Wall -W -I. -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wbad-function-cast -
Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -
Wredundant-decls -Wdisabled-optimization -Winline t.c
--
Summary: always inline short functions if inlining would be as
small as non-inlined code
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ash at onezero dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 19:14 --- 3.3.x is old and does not have the inlining improvements that went into 3.4.x. You might want to try 3.4.x or even 4.0.x. 4.1.x (the mainline) has better inlining still. But without a full testcase, we won't know if this is fixed. I am thinking it is for 4.0.x or 4.1.x. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- I'm on Cywin and couldn't find a later version of gcc - is there one somewhere that I can use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- (Cygwin) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:19 --- (In reply to comment #10) one of the key differentiators with iostreams is type safety, which is effectively broken with the current behavior. By the way, I don't understand what do you mean by type safety in this context. Because the behavior of do_put *is* specified exactly as if printf were called, either printf(%x) is able to digest somehow a signed integer or not, there isn't much more to say. Currently, the impression is that according to the C99 standard is *not*, according to the C89 standard *maybe* it is. Then the issue would be, in case, only that of adjusting the C++ standard not to trigger undefined behavior from the printf function that it uses to functionally specify the mandated behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 19:22 --- Hmm.. this is I believe a bug, but a very hard one to trigger. 1) This bug is very sensitive. It only occurs if the const_iterator member function is const and the iterator member function isn't. It doesn't appear for a pair of normal functions. 2) Just to point it out, if you try only allowing the first function t(iterator f), then the code won't compile, as it tries and fails to instansiated the templated constructor. The obvious way to fix this would be to change the templated constructor so that it only took the const version of the iterator. Unfortunatly I don't believe thats possible without passing extra information by more template parameters, which would break binary compatability. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:33 --- (In reply to comment #2) Unfortunatly I don't believe thats possible without passing extra information by more template parameters, which would break binary compatability. I'm not going to discuss now the substance of this issue (hopefully soon!) but I don't think the binary compatibility thing is obviously true. When two different object modules are built, each one can use the appropriate constructor, and there are no risks of mixups when (possible) weak symbols are merged because the signatures would be different in this case (a very nasty issue instead is when you change *only* the return type of a function, in that case, as Geoff kindly reminded us, there are risks because the sig is the same!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:37 --- (In reply to comment #3) Unfortunatly I don't believe thats possible without passing extra information by more template parameters, which would break binary compatability. In short, in my preliminary opinion, we can well envisage this assuming anything we do actually changes the signature of the constructor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23770] New: unaligned buffers in i/o library force use of memcpy()
Currently, the buffers for reading/writing integers and reals in the i/o library are of type char[], which forces the use of memcpy(), as in the fix for PR 23356. It would be better for performance if suitable alignment could be forced on the buffers. -- Summary: unaligned buffers in i/o library force use of memcpy() Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
[Bug c++/23771] New: [4.0.2 regression] Constant template argument not recognized as such
This code
--
template typename T struct length {
static const int value = 3;
};
template typename T, int L = lengthT::value struct S {};
template typename T
ST bar (T);
template int dim void foo () {
bar (1);
}
-
Used to compile with gcc 4.0.1pre (20050531), but it doesn't any more with
today's snapshot of the 4.0.2 branch. It apparently doesn't recognize
lengthT::value as an integer constant expression any more:
/home/bangerth/bin/gcc-4.0.2-pre/bin/c++ -c source/grid/grid_generator.cc
source/grid/grid_generator.cc: In function #8216;void foo()#8217;:
source/grid/grid_generator.cc:11: error: #8216;lengthint::value#8217; is
not a valid
template argument for type #8216;int#8217; because it is a non-constant
expression
source/grid/grid_generator.cc:11: error: no matching function for call to
#8216;bar(int)#8217;
I don't really see how to work around this problem short of specifying the
value of the second template argument by hand.
This bug will (again) prevent 4.0.2 from being able to compile one of the
proposed SPEC 2005 benchmarks (4.0.1 couldn't do this due to PR 21799). It
would be nice if this could be fixed before 4.0.2 comes out.
Thanks
Wolfgang
--
Summary: [4.0.2 regression] Constant template argument not
recognized as such
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org,mmitchel at gcc dot gnu
dot org,nathan at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23691] [4.0 Regression] `mpl_::bool_false::value' is not a valid template argument for type `bool' because it is a non-constant expression
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03 --- This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre but doesn't anymore with today's 4.0.2pre. W. *** This bug has been marked as a duplicate of 23771 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug c++/23771] [4.0.2 regression] Constant template argument not recognized as such
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03 --- *** Bug 23691 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23771] [4.0/4.1 regression] Constant template argument not recognized as such
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:06 --- Used to work with 4.1 20050822 but does not with 4.1 20050903. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-07 20:06:13 date|| Summary|[4.0.2 regression] Constant |[4.0/4.1 regression] |template argument not |Constant template argument |recognized as such |not recognized as such Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23691] [4.0 Regression] `mpl_::bool_false::value' is not a valid template argument for type `bool' because it is a non-constant expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:06 --- (In reply to comment #11) This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre but doesn't anymore with today's 4.0.2pre. Actually it is not really as this one works on the mainline. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:06
---
You are right, I previously didn't think it was possible without adding some
more template parameters.
However, I should have known there is nothing you can't do with a few templates
:)
How about something like:
templatetypename _Iter
inline __normal_iterator(const __normal_iterator_Iter,
_Container __i,
typename std::__enable_ifint,
std::tr1::is_convertible_Iter,
_Iterator::value::__type = 0)
: _M_current(__i.base()) { }
Which shouldn't effect any existing code, as unless _Iter is convertable to
_Iterator, _M_current(__i.base
()) isn't going to compile. I'm adding
#includecpp_type_traits.h
#includetr1/type_traits
to do this, and of course I imagine we'll have to cut is_convertable out of
type_traits...
I haven't done a full test of this yet, but it seems reasonable at first glance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c++/23771] [4.0/4.1 regression] Constant template argument not recognized as such
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:08 --- Note unlike PR 23691, this one does ___not___ work on the mainline. They might be the same issue but we won't really know until either one is fixed. -- What|Removed |Added OtherBugsDependingO||23691 nThis|| Known to fail||4.1.0 4.0.2 Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23691] [4.0 Regression] `mpl_::bool_false::value' is not a valid template argument for type `bool' because it is a non-constant expression
-- What|Removed |Added CC||bangerth at dealii dot org Last reconfirmed|2005-09-06 18:49:14 |2005-09-07 20:12:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:14 --- (In reply to comment #5) How about something like: Yes, in my mind earlier today I considered that solution. In principle should work. However, there are issues, I'm afraid: optimization issues with the extra dummy parameter (right?) and, well, maybe we can figure out something cleaner (in particular, I'm under the impression that, as a policy, we do our best to minimize the enable_if-isms) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 20:16 --- Subject: Bug 23419 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 20:16:47 Modified files: libgfortran: ChangeLog libgfortran/io : write.c Log message: PR libfortran/23419 * io/write.c (extract_int): Use memcpy to access buffer. (extract_uint): Ditto. (extract_real): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.295r2=1.296 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gccr1=1.46r2=1.47 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
