[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
--- Comment #3 from doug dot gregor at gmail dot com 2008-09-24 06:01 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01667.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug fortran/37634] New: Fix libgfortran compiling to support GCC_NO_EXECUTABLES
See: http://gcc.gnu.org/ml/fortran/2008-09/msg00380.html and following emails. The configure script does link tests which cause some kinds of cross compilations to fail. Solution (cf. email thread, see above link): a) Approved patch in the link above b) Remove AC_LIBTOOL_DLOPEN which does not seem to be used c) Add an if-block around the AC_CHECK_FUNCS d) Check what else is needed, e.g. AC_CHECK_LIB -- Summary: Fix libgfortran compiling to support GCC_NO_EXECUTABLES Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: build 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=37634
[Bug fortran/37626] ICE for automatic deallocation of character result variable
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-24 07:02 --- Subject: Bug 37626 Author: burnus Date: Wed Sep 24 07:01:18 2008 New Revision: 140624 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140624 Log: 2008-09-24 Tobias Burnus [EMAIL PROTECTED] PR fortran/37626 * trans-array.c (gfc_trans_deferred_array): Don't auto-deallocate result variables. 2008-09-24 Tobias Burnus [EMAIL PROTECTED] PR fortran/37626 * gfortran.dg/allocatable_function_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37626
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #4 from tim dot vanholder at anubex dot com 2008-09-24 07:03 --- Then perhaps either configure should reject the too-old version, or the testcase should detect this situation and either skip the tests in question and/or report that MPFR is too old. The situation as it stands is not very helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-24 07:18 --- Then perhaps either configure should reject the too-old version, or the testcase should detect this situation and either skip the tests in question and/or report that MPFR is too old. The situation as it stands is not very helpful. See the comment at the beginning of the testcase. Moreover, configure should have reported that the version of MPFR is not optimal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-24 08:05 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-24 08:05 --- Subject: Bug 37583 Author: pault Date: Wed Sep 24 08:04:26 2008 New Revision: 140626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140626 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37583 * decl.c (scalarize_intrinsic_call): Both subroutines and functions can give a true for get_proc_mame's last argument so remove the gfc_current_ns-proc_name-attr.function. resolve.c (resolve_actual_arglist): Add check for recursion by reference to procedure as actual argument. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37583 * gfortran.dg/entry_18.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/entry_18.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/decl.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug fortran/35945] Complex module-based overloading fails
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Subject: Bug 35945 Author: pault Date: Wed Sep 24 08:12:47 2008 New Revision: 140627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * resolve.c (resolve_fl_variable_derived): Remove derived type comparison for use associated derived types. Host association of a derived type will not arise if there is a local derived type whose use name is the same. PR fortran/36700 * match.c (gfc_match_call): Use the existing symbol even if it is a function. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * gfortran.dg/host_assoc_types_2.f90: New test. PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/match.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35945
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Subject: Bug 36700 Author: pault Date: Wed Sep 24 08:12:47 2008 New Revision: 140627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140627 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * resolve.c (resolve_fl_variable_derived): Remove derived type comparison for use associated derived types. Host association of a derived type will not arise if there is a local derived type whose use name is the same. PR fortran/36700 * match.c (gfc_match_call): Use the existing symbol even if it is a function. 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/35945 * gfortran.dg/host_assoc_types_2.f90: New test. PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_types_2.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/match.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug fortran/35945] Complex module-based overloading fails
--- Comment #4 from pault at gcc dot gnu dot org 2008-09-24 08:14 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35945
[Bug fortran/37635] New: Fortran 2008: Support LEADZ / TRAILZ
Requested by Richard Townsend at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1e4130b9720e4f2a LEADZ and TRAILZ are rather common vendor extensions, e.g. supported by the Intel compiler (it also allows for logical arguments). LEADZ (I) Description. Number of leading zero bits. Argument. I shall be of type integer. Result Value. If all of the bits of I are zero, the result value is BIT SIZE (I). [...] TRAILZ (I) Description. Number of trailing zero bits. Argument. I shall be of type integer. The implementation should be relatively easy using the following built-ins, however, one presumably needs a special case for ZERO. BUILT_IN_CLZ* These functions return the number of leading 0-bits in a, starting at the most significant bit position. If a is zero, the result is undefined. and BUILT_IN_CTZ* These functions return the number of trailing 0-bits in a, starting at the least significant bit position. If a is zero, the result is undefined. (Description copied from http://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html) For compile-time simplification, MPFR does not seem to provide a ready-to-use function; if one cooks up something oneself, one needs to check endian issues (though there might be none). -- Summary: Fortran 2008: Support LEADZ / TRAILZ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement 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=37635
[Bug fortran/36700] [4.3/4.4 Regression] ICE on calling a function
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-24 08:28 --- Subject: Bug 36700 Author: pault Date: Wed Sep 24 08:27:27 2008 New Revision: 140628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140628 Log: 2008-09-24 Paul Thomas [EMAIL PROTECTED] PR fortran/36700 * gfortran.dg/host_assoc_call_2.f90: Correct typo. Modified: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36700
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's behaviour,
just like it would be unreasonable that -pedantic would silently change 'long
long i = 2LL 34;' to 'long i = 0;'. With today's complex build systems it is
not that difficult to get -fno-exceptions without noticing and then get code
that works differently than intended (and I'm not making this up, I had such a
real case).
If people really want code with exception handling to work with both
-fexception states, then they need to write the code with that in mind and then
they can as well just use __try/__catch macros the way libstdc++ does now, just
without breaking the code for the rest of people who can run into trouble if
the compiler/libraries try to outguess them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #3 from gcc at spatium dot org 2008-09-24 09:37 --- Subject: Re: [4.4 Regression] gcc-4.4-20080919 ada build failure pinskia at gcc dot gnu dot org wrote 767 bytes: Can you try this again? same thing with latest trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #84 from aldot at gcc dot gnu dot org 2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
* has one (eg: FRV)
*/
extern const unsigned long kallsyms_num_syms
__attribute__((weak, section(.rodata)));
int main(void) {
return !!kallsyms_num_syms;
}
$ /there.arm/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -S -o - pr-weak.c -v
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with: /srcs/toolchain_build_arm_nofpu/gcc-4.4.0/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibcgnueabi --enable-languages=c,fortran
--with-sysroot=/there.arm
--with-build-time-tools=/there.arm/usr/arm-linux-uclibcgnueabi/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/srcs/toolchain_build_arm_nofpu/gmp
--with-mpfr=/srcs/toolchain_build_arm_nofpu/mpfr --disable-nls --enable-threads
--disable-multilib --with-float=soft --with-abi=aapcs-linux --disable-libssp
--disable-libssp --disable-libmudflap --disable-libgomp
--enable-decimal-float=no
Thread model: posix
gcc version 4.4.0 20080923 (experimental) [trunk revision 140602] (GCC)
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'
/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/cc1 -quiet -v
-iprefix /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/ pr-weak.c
-quiet -dumpbase pr-weak.c -mfloat-abi=soft -mabi=aapcs-linux -auxbase-strip -
-Os -version -o -
ignoring nonexistent directory
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include
ignoring nonexistent directory /there.arm/usr/local/include
ignoring duplicate directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include
ignoring duplicate directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed
ignoring nonexistent directory
/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include
#include ... search starts here:
#include ... search starts here:
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include
/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed
/there.arm/usr/include
End of search list.
GNU C (GCC) version 4.4.0 20080923 (experimental) [trunk revision 140602]
(arm-linux-uclibcgnueabi)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 071bc0f306e6057c8a651fee23ec8dfa
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file pr-weak.c
.text
.align 2
.global main
.type main, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldr r0, [r3, #0]
subsr0, r0, #0
movne r0, #1
bx lr
.L4:
.align 2
.L3:
.word kallsyms_num_syms
.size main, .-main
.ident GCC: (GNU) 4.4.0 20080923 (experimental) [trunk revision
140602]
.section.note.GNU-stack,,%progbits
COMPILER_PATH=/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../libexec/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/bin/
LIBRARY_PATH=/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../lib/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/lib/:/there.arm/lib/:/there.arm/usr/lib/
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'
works with 4.3.2 configured in the same way.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug fortran/35723] Can't use run-time array element in character declaration
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-28 19:40:15 |2008-09-24 09:59:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35723
[Bug libgcj/37636] New: [4.4 regression] java tools are unable to find resource files
seen with 20080923 from the trunk, try running any of the tools:
$ /usr/lib/gcc-snapshot/bin/gjar -help
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(natClass.cc:792)
at gnu.classpath.tools.common.Messages.getString(Messages.java:60)
at
gnu.classpath.tools.common.ClasspathToolParser.getVersionString(ClasspathToolParser.java:65)
at
gnu.classpath.tools.common.ClasspathToolParser.init(ClasspathToolParser.java:81)
at
gnu.classpath.tools.common.ClasspathToolParser.init(ClasspathToolParser.java:76)
at gnu.classpath.tools.jar.Main$JarParser.init(Main.java:151)
at gnu.classpath.tools.jar.Main.initializeParser(Main.java:177)
at gnu.classpath.tools.jar.Main.run(Main.java:268)
at gnu.classpath.tools.jar.Main.main(Main.java:284)
Caused by: java.util.MissingResourceException: Bundle
gnu.classpath.tools.common.Messages not found for locale en_US by classloader
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.util.ResourceBundle.getBundle(ResourceBundle.java:410)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:231)
at gnu.classpath.tools.common.Messages.clinit(Messages.java:50)
at java.lang.Class.initializeClass(natClass.cc:780)
...8 more
--
Summary: [4.4 regression] java tools are unable to find resource
files
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug middle-end/37637] New: Build fails with reserved constraints
The build of the Debian gcc-snapshot package, version 20080923, fails to build with this output from some sort of constraints check. This constraints are arch specific. build/genpreds -h ../../src/gcc/config/s390/s390.md tmp-preds.h ../../src/gcc/config/s390/constraints.md:122: constraint letter 'G' is reserved for const_double constraints ../../src/gcc/config/s390/constraints.md:129: constraint letter 'I' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:135: constraint letter 'J' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:141: constraint letter 'K' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:147: constraint letter 'L' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:157: constraint letter 'M' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:163: constraint letter 'P' is reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:197: constraint names beginning with 'N' (NxQS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:203: constraint names beginning with 'N' (NxQD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:209: constraint names beginning with 'N' (N3HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:215: constraint names beginning with 'N' (N2HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:221: constraint names beginning with 'N' (N1SD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:227: constraint names beginning with 'N' (N1HS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:233: constraint names beginning with 'N' (N1HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:239: constraint names beginning with 'N' (N0SD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:245: constraint names beginning with 'N' (N0HS0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:251: constraint names beginning with 'N' (N0HD0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:257: constraint names beginning with 'N' (NxQDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:263: constraint names beginning with 'N' (N1SDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:269: constraint names beginning with 'N' (N0SDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:275: constraint names beginning with 'N' (N3HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:281: constraint names beginning with 'N' (N2HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:287: constraint names beginning with 'N' (N1HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:293: constraint names beginning with 'N' (N0HDF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:299: constraint names beginning with 'N' (N0HSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:305: constraint names beginning with 'N' (N1HSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:311: constraint names beginning with 'N' (NxQSF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:317: constraint names beginning with 'N' (NxQHF) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:323: constraint names beginning with 'N' (NxQH0) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:336: constraint names beginning with 'O' (Os) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:345: constraint names beginning with 'O' (Op) are reserved for const_int constraints ../../src/gcc/config/s390/constraints.md:354: constraint names beginning with 'O' (On) are reserved for const_int constraints -- Summary: Build fails with reserved constraints Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: waldi at debian dot org GCC target triplet: s390-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
---
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
We have to be careful, in some cases. For example:
extern int f();
template typename T
struct S {
static int i;
};
template typename T
int ST::i = f();
int main() {
try {
return 0;
} catch (...) {
return Sint::i;
}
}
This program, IIRC, is guaranteed to call f, as a side-effect of the
presence of the catch-clause? Of course, the C++ FE could still process
the catch clause; my only point is that we cannot literally just throw
away the catch clause.
I don't objection to -fno-exceptions silently discarding catch clauses,
as long as we avoid the kind of problem above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/37638] New: ICE in update_arglist_pass
Current version of gfortran dies with an ICE on the attached invalid code. - log --- [EMAIL PROTECTED] F03]$ gfortran -v -c foo-ext.f03 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnutest --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080923 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' /usr/local/gnutest/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 foo-ext.f03 -quiet -dumpbase foo-ext.f03 -mtune=generic -auxbase foo-ext -version -fintrinsic-modules-path /usr/local/gnutest/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/cc5PDDfU.s GNU Fortran (GCC) version 4.4.0 20080923 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080923 (experimental), GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 foo-ext.f03:10.13: procedure, pass(a) :: makenull 1 Error: Procedure 'makenull' with PASS(a) at (1) has no argument 'a' f951: internal compiler error: in update_arglist_pass, at fortran/resolve.c:4380 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in update_arglist_pass Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 13:51 --- We need to look at CALL_EXPR_FN's type because the decltype of a call retrieves the return type of the the function called, which may be a REFERENCE_TYPE. The type of the expression will have stripped away that reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-24 13:51 --- Created an attachment (id=16400) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16400action=view) test case ICE-on-invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #2 from jkolb at wsi dot com 2008-09-24 14:07 --- Binutils 2.19.50 Yes I have. The linker switch does not help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 --- Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 14:39:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug fortran/37638] ICE in update_arglist_pass
--- Comment #3 from sfilippone at uniroma2 dot it 2008-09-24 14:50 --- (In reply to comment #2) Thanks for the report Salvatore, I'll take this one on. It seems the new F2003 features are starting to getting used, from the bug-noise :D Unfortunately these features are not going to be very useful until CLASS() is implemented; indeed, the code is invalid, but if you change pass(a) into pass(m) it would still be invalid because the makenull procedure should be written with a CLASS() and not a TYPE() argument. In fact, if you comment the second contained subroutine the ICE goes away. As soon as CLASS() is in you (and PaulT) may expect a lot more noise :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37638
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #3 from brian at dessent dot net 2008-09-24 15:24 --- Subject: Re: auto-import of constant data results in a crash at runtime So, is the segment containing the reference to ff_log2_tab writable? This still sounds like a linker issue not a compiler issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug bootstrap/37639] New: Bootstrap fails with may be used uninitialized warning in c-parser.c
-- Summary: Bootstrap fails with may be used uninitialized warning in c-parser.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc64-apple-darwin9.5.0 GCC host triplet: powerpc64-apple-darwin9.5.0 GCC target triplet: powerpc64-apple-darwin9.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
[Bug bootstrap/37639] Bootstrap fails with may be used uninitialized warning in c-parser.c
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 15:34
---
Created an attachment (id=16401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16401action=view)
macro-expanded source of c-parser.c
Sorry for hitting return instead of tab in the initial report ...
Configured and bootstrapped with
[descartes:objdirs/mainline/gcc] lucier% cat
../../../mainline/build-and-check-gcc-64
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64'
--build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0
--target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/
--with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/
--with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.4.0-64
--with-libiconv-prefix=/usr --with-system-zlib; make -j 4 bootstrap
BOOT_LDFLAGS='-Wl,-search_paths_first' build.log (make install) (make
-k -j 8 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
check.log ; make mail-report.log)
Error is
[descartes:objdirs/mainline/gcc] lucier%
/Users/lucier/programs/gcc/objdirs/mainline/./prev-gcc/xgcc
-B/Users/lucier/programs/gcc/objdirs/mainline/./prev-gcc/
-B/pkgs/gcc-4.4.0-64/powerpc64-apple-darwin9.5.0/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../../mainline/gcc -I../../../mainline/gcc/.
-I../../../mainline/gcc/../include -I./../intl
-I../../../mainline/gcc/../libcpp/include -I/sw/include/ -I/sw/include/
-I../../../mainline/gcc/../libdecnumber
-I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber
../../../mainline/gcc/c-parser.c -o c-parser.o -save-temps
cc1: warnings being treated as errors
../../../mainline/gcc/c-parser.c: In function 'c_parser_binary_expression':
../../../mainline/gcc/c-parser.c:4579: error: 'binary_loc' may be used
uninitialized in this function
../../../mainline/gcc/c-parser.c:4579: note: 'binary_loc' was declared here
preprocessed source included as an attachment
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #4 from jkolb at wsi dot com 2008-09-24 15:35 --- I'm not sure, I don't have access to that machine right now. Kai Tietz (from the mingw-w64 project) thought it might be the linker as well. How do I hand the bug off to the linker folks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #1 from kargl at gcc dot gnu dot org 2008-09-24 16:19 --- (In reply to comment #0) For compile-time simplification, MPFR does not seem to provide a ready-to-use function; if one cooks up something oneself, one needs to check endian issues (though there might be none). I think you mean GMP because we're concerned with INTEGER types. See mpz_scan0 and mpz_scan1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug regression/37640] New: Misuse of __sync_lock_test_and_set causes ICE
A gcc build from today (gcc version 4.4.0 20080924) gets an ICE on PowerPC when
building this (admittedly broken) code:
# gcc -m64 -O2 -c test.c
struct foo {
int a;
char lock;
};
struct foo *foo;
void testcase()
{
__sync_lock_test_and_set((foo-lock), 0);
}
It compiles if building 32bit. Even so, I wonder if gcc should warn when the
variable is incompatible with __sync_* builtins.
--
Summary: Misuse of __sync_lock_test_and_set causes ICE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anton at samba dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 16:49 --- (In reply to comment #4) I think this was fixed for 4.3.0: HP, can you try this again on cris? At 140627, the problem is still there on the 4.3 branch for CRIS. I'll attach a diff of the generated assembly of -O2 compared to -O2 -fno-if-conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 16:51 --- Created an attachment (id=16402) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16402action=view) Diff of asembly of -O2 vs -O2 -fno-if-conversion at r.140627 See previous comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug rtl-optimization/26479] suboptimal register allocation for return register
--- Comment #7 from hp at gcc dot gnu dot org 2008-09-24 16:57 --- I guess I should turn the code in the description into a testcase in gcc.dg so target maintainers can add their xfailed scan-assembler-not and we'd see xpasses if/when this is magically fixed... (After the IRA adjustments for CRIS!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26479
[Bug ada/37641] New: FILE_WRITE_PROPERTIES is deprecated
adaint.c uses a macro for mingw called FILE_WRITE_PROPERTIES. This has long since been deprecated, and is instead replaced with FILE_WRITE_EA. Both macros are defined to the same value (0x0010), but one does not exist in current versions (such as mingw-w64, the 64-bit port). I recommend updating to the new macro. The below is a patch that should work: === --- ../../../gcc/gcc/ada/adaint.c (revision 140599) +++ ../../../gcc/gcc/ada/adaint.c (working copy) @@ -1923,7 +1923,7 @@ __gnat_set_OWNER_ACL (wname, DENY_ACCESS, FILE_WRITE_DATA | FILE_APPEND_DATA | - FILE_WRITE_PROPERTIES | FILE_WRITE_ATTRIBUTES); + FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES); SetFileAttributes (wname, GetFileAttributes (wname) | FILE_ATTRIBUTE_READONLY); #elif ! defined (__vxworks) ! defined(__nucleus__) -- Summary: FILE_WRITE_PROPERTIES is deprecated Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37641
[Bug c/37642] New: GCC applies signed strict-overflow rules to unsigned short type
I'll submit a testcase that apparently demonstrates that gcc is trying to apply signed strict overflow rules to an unsigned short type, at least on 32 bit machines when short is 16 bit. Here is the output: arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c testcase.c: In function incr_counter: testcase.c:13: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false this is from gcc 4.3.1; my native build also has the same semantics, and I've tested with 4.2.4 also. The thing is that the type is unsigned (even if it is smaller than the target machine register), so that it can overflow and it can be detected (costly perhaps, but can). -- Summary: GCC applies signed strict-overflow rules to unsigned short type Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexandre dot nunes at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29 --- Created an attachment (id=16403) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403action=view) This is the first testcase. compile with gcc -O2 -W -Wall -Wstrict-overflow=5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug ada/37641] FILE_WRITE_PROPERTIES is deprecated
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-09-24 17:32 --- FILE_WRITE_PROPERTIES is deprecated and even the documentation is removed from msdn. So I agree that FILE_WRITE_EA should be used instead. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37641
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
--- Comment #2 from dlenski at gmail dot com 2008-09-24 17:43 --- Hi Andrew, It seems to me that these modifiers are quite necessary for flexible x86 assembly. What is the point of the q and Q constraints if there's no way to specifically refer to the 16-bit or 8-bit components of the selected register? And are you sure there built-in functions to invoke the rol/ror/xhcg instructions? I don't see any in the 4.3 docs. Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #2 from pinskia at gmail dot com 2008-09-24 17:44 --- Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short type When doing addition unsigned short is promoted to an signed int. So this is not a bug. That is unsigned short + 1 is a signed int since 1 is a signed int. Sent from my iPhone On Sep 24, 2008, at 10:29 AM, alexandre dot nunes at gmail dot com [EMAIL PROTECTED] wrote: I'll submit a testcase that apparently demonstrates that gcc is trying to apply signed strict overflow rules to an unsigned short type, at least on 32 bit machines when short is 16 bit. Here is the output: arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c testcase.c: In function âincr_counterâ: testcase.c:13: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false this is from gcc 4.3.1; my native build also has the same semantics, and I've tested with 4.2.4 also. The thing is that the type is unsigned (even if it is smaller than the target machine register), so that it can overflow and it can be detected (costly perhaps, but can). -- Summary: GCC applies signed strict-overflow rules to unsigned short type Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexandre dot nunes at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #58 from jason at redhat dot com 2008-09-24 19:21 ---
Subject: Re: exception_defines.h #defines try/catch
l dot lunak at suse dot cz wrote:
--- Comment #56 from l dot lunak at suse dot cz 2008-09-24 08:50 ---
(In reply to comment #55)
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
It seems unreasonable to me that gcc would silently modify code's behaviour,
The change I was talking about doesn't modify behavior. If there are no
exceptions, catch blocks will never be executed, so we can optimize them
away in the presence of -fno-exceptions.
This program, IIRC, is guaranteed to call f, as a side-effect of the
presence of the catch-clause? Of course, the C++ FE could still process
the catch clause; my only point is that we cannot literally just throw
away the catch clause.
True, it would be more like { X } if (0) ...
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/37643] New: fortran doesn't build on 4.4.0 for vax
When cross-compiling for vax--netbsdelf, fortran doesn't build. I have a NetBSD/vax 4.99.72 install symlinked, and am using binutils 2.19.50.20080923. gcc sources are subversion rev 140638. It gets to here and stops: libtool: compile: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/ -B/usr/local/vax--netbsdelf/bin/ -B/usr/local/vax--netbsdelf/lib/ -isystem /usr/local/vax--netbsdelf/include -isystem /usr/local/vax--netbsdelf/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../libgfortran/io -I../../../libgfortran/../gcc -I../../../libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT c99_functions.lo -MD -MP -MF .deps/c99_functions.Tpo -c ../../../libgfortran/intrinsics/c99_functions.c -o c99_functions.o ../../../libgfortran/intrinsics/c99_functions.c:539: warning: no previous prototype for 'roundl' ../../../libgfortran/intrinsics/c99_functions.c:640: warning: no previous prototype for 'lroundl' ../../../libgfortran/intrinsics/c99_functions.c:667: warning: no previous prototype for 'llroundl' ../../../libgfortran/intrinsics/c99_functions.c:679: warning: no previous prototype for 'log10l' ../../../libgfortran/intrinsics/c99_functions.c:717: warning: no previous prototype for 'floorl' ../../../libgfortran/intrinsics/c99_functions.c:743: warning: no previous prototype for 'fmodl' ../../../libgfortran/intrinsics/c99_functions.c: In function 'tgamma': ../../../libgfortran/intrinsics/c99_functions.c:1455: warning: floating constant truncated to zero ../../../libgfortran/intrinsics/c99_functions.c:1457: warning: target format does not support infinity /var/tmp//ccY9ySD8.s: Assembler messages: /var/tmp//ccY9ySD8.s:712: Fatal error: Junk at end of expression QNaN Closer examination reveals that the line the assembler is choking on is: movd $0d+QNaN,%r1 Fortran did build in the past on 4.4.0; I have a version dated 2008.04.10. -- Summary: fortran doesn't build on 4.4.0 for vax Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hbent at cs dot oberlin dot edu GCC build triplet: i386-unknown-netbsdelf4.99.72 GCC host triplet: i386-unknown-netbsdelf4.99.72 GCC target triplet: vax--netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37643
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 19:55 --- How is this broken code? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #2 from anton at samba dot org 2008-09-24 20:07 --- After reading the gcc documentation I guess it is valid, and the 32bit lwarx/stwcx will overlap but not change surrounding memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug target/37640] Misuse of __sync_lock_test_and_set causes ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-24 20:16 --- Something like this fixes the issue: Index: config/rs6000/rs6000.c === --- config/rs6000/rs6000.c (revision 140638) +++ config/rs6000/rs6000.c (working copy) @@ -14082,7 +14082,8 @@ rs6000_expand_compare_and_swapqhi (rtx d HOST_WIDE_INT imask = GET_MODE_MASK (mode); /* Shift amount for subword relative to aligned word. */ - addrSI = force_reg (SImode, gen_lowpart_common (SImode, XEXP (mem, 0))); + addrSI = force_reg (GET_MODE (XEXP (mem, 0)), XEXP (mem, 0)); + addrSI = force_reg (SImode, gen_lowpart_common (SImode, addrSI)); shift = gen_reg_rtx (SImode); emit_insn (gen_rlwinm (shift, addrSI, GEN_INT (3), GEN_INT (shift_mask))); --- CUT --- gen_lowpart_common does not work on non regs so force the addition to memory first and then get the lowerpart. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|__sync_lock_test_and_set|Misuse of |causes ICE |__sync_lock_test_and_set ||causes ICE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37640
[Bug c++/36461] [c++0x] Exception throws don't use rvalue reference constructors
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-09-24 20:20 ---
GCC is doing the right thing here. In this constructor:
Thing2(Thing2 o) : Thing(o) { }
the parameter o is treated as an lvalue, because it has a name. Using
std::move(o) to treat it as an rvalue.
Similarly, there are no automatically generated move constructors or
move-assignment operators, so if you leave Thing2() empty, you'll just get the
copy constructor and therefore do a copy.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-24 20:36 --- What happens if you don't use profiledbootstrap but instead bootstrap? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42 --- (In reply to comment #2) Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short type When doing addition unsigned short is promoted to an signed int. So this is not a bug. That is unsigned short + 1 is a signed int since 1 is a signed int. Sent from my iPhone Hah, living and learning. That actually makes sense, thanks, I'll refine the test. -- alexandre dot nunes at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug bootstrap/37304] [4.4 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
--- Comment #5 from hp at gcc dot gnu dot org 2008-09-24 21:10 --- (In reply to comment #4) FWIW, this happens inside libtool configure tests, so I guess it is harmless inside gcc/. Do you see this in other directories' configure outputs, too, No. and if yes, can you post a little more context (esp. the 5 or so lines following what you posted would have been interesting)? I'll attach the corresponding *native* x64-64 build of r139963, where the behavior is visible for each stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug bootstrap/37304] [4.4 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-24 21:15 --- Created an attachment (id=16404) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16404action=view) bzip2:ed native x64-64-linux build_log The build_log from GeoffK's contrib/regression/btest-gcc.sh) of trunk r139963 of a x86_64-unknown-linux-gnu test with in-tree binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug fortran/37635] Fortran 2008: Support LEADZ / TRAILZ
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 --- I'll see this weekend if I can take care of this. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-24 22:28:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
--- Comment #3 from n dot pipenbrinck at cubic dot org 2008-09-24 22:41 --- ROL/ROR on the native integer size is not supported via intrinsics, but the compiler will fold two shifts into a rotate. If I want to manipulate only the lower 16 bit of an 32 bit integer (e.g. issue a rolw) assembly is the only way it's currently possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug fortran/37644] New: compiler Segmentation fault
Open MP directives in conjunction with LAM MPI calls is causing compiler to fail: (bash) niwot.pts/3% export LAMHF77=/z/stoch/home/rlnaff/usr/local/bin/gfortran4.3.2 (bash) niwot.pts/3% mpif77 -g -fopenmp -c reorder_parent.f90 reorder_parent.f90:470: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (bash) niwot.pts/3% mpif77 -v -save-temps -g -fopenmp -c reorder_parent.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: /z/stoch/home/rlnaff/gcc_source/gcc-4.3.2//configure --prefix=/z/stoch/home/rlnaff/usr/local --program-suffix=4.3.2 -with-local-prefix=/z/stoch/home/rlnaff/usr/local --with-gnu-as --with-gnu-ld --enable-threads --with-cpu-32=cpu --enable-languages=all --with-gmp --with-mpfr Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-I/usr/local/include' '-pthread' '-v' '-save-temps' '-g' '-fopenmp' '-c' '-mtune=generic' '-pthread' /a/stoch/home/rlnaff/usr/local/bin/../libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 reorder_parent.f90 -quiet -dumpbase reorder_parent.f90 -mtune=generic -auxbase reorder_parent -g -version -fopenmp -I/usr/local/include -fintrinsic-modules-path /a/stoch/home/rlnaff/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o reorder_parent.s GNU F95 (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129368 reorder_parent.f90:470: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: compiler Segmentation fault Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rlnaff at usgs dot gov GCC build triplet: see description below GCC host triplet: see description below GCC target triplet: see description below http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37644
[Bug libgcj/37636] [4.4 regression] java tools are unable to find resource files
--- Comment #1 from gnu_andrew at member dot fsf dot org 2008-09-25 01:47 --- I'm not sure when 4.3 branched, but David Daney's locale patch (switching from gcj's locales to Classpath's) might have had an effect (2008-03-04). It's the only locale change I can see from this year. The current 4.3 branch does still work fine. The missing resources are in libjava/classpath/tools/resource. None of them are locale-specific. ResourceBundle is used as-is from Classpath without being overridden or amended. It may be a classloader issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug rtl-optimization/36758] [4.3/4.4 Regression] addition moved out of the loop when used with an argument
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-25 02:52 --- This happens also for x86_64. on the trunk: L2: movq%rbx, %rdi call_f0 testl %eax, %eax jne L2 4.0.1: L3: leaq-4(%rbp), %rdi call_f0 testl %eax, %eax jne L3 --- CUT --- With the fwrprop patch which I am working on and disabling move loop invariants, we get back: L2: leaq-4(%rbp), %rdi call_f0 testl %eax, %eax jne L2 -- CUT --- move-loop-invariants still moves this out of the loop though. So to answer Richard's question about this being a target issue, since it is also happens on x86_64 and move loop invariants does not take into account the cost of the move instruction, I am going to say this is a move loop invariant issue (after I fix the fwprop one). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc*-*-*|powerpc*-*-*, x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
[Bug libgcj/37636] [4.4 regression] java tools are unable to find resource files
--- Comment #2 from gnu_andrew at member dot fsf dot org 2008-09-25 03:20 --- Interestingly: $ /home/andrew/build/gcj/bin/gcj --version gcj (GCC) 4.4.0 20080913 (experimental) [gcj/classpath-098-merge-branch revision 140651] $ /home/andrew/build/gcj/bin/gjar --version jar (GNU Classpath) 0.98-pre $ /home/andrew/build/gcj/bin/gjar --help Usage: jar -ctxui [OPTIONS] jar-file [-C DIR FILE] FILE... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37636
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #1 from drangon dot mail at gmail dot com 2008-09-25 04:45 --- Created an attachment (id=16405) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16405action=view) output of gcc -E -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #2 from drangon dot mail at gmail dot com 2008-09-25 04:47 --- Created an attachment (id=16406) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16406action=view) output of nm, the object is build by gcc -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #3 from drangon dot mail at gmail dot com 2008-09-25 04:48 --- Created an attachment (id=16407) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16407action=view) output of nm, the object is build by gcc -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #4 from drangon dot mail at gmail dot com 2008-09-25 04:48 --- Created an attachment (id=16408) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16408action=view) output of objdump, the object is build by gcc -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #5 from drangon dot mail at gmail dot com 2008-09-25 04:49 --- Created an attachment (id=16409) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16409action=view) output of objdump, the object is build by gcc -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug target/37120] g++ failed to compile code dVolume *= 1 + pow(10.0, -5.0);
--- Comment #4 from drangon dot mail at gmail dot com 2008-09-25 04:51 --- (From update of attachment 16070) not for this bug -- drangon dot mail at gmail dot com changed: What|Removed |Added Attachment #16070|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37120
[Bug target/37120] g++ failed to compile code dVolume *= 1 + pow(10.0, -5.0);
--- Comment #5 from drangon dot mail at gmail dot com 2008-09-25 04:51 --- (From update of attachment 16071) not for this bug -- drangon dot mail at gmail dot com changed: What|Removed |Added Attachment #16071|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37120
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #6 from nightstrike at gmail dot com 2008-09-25 05:00 --- What is the output of g++ -v? Are you using the win32 cross compiler, or the win64 native compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
