[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868
--- Comment #4 from krebbel at gcc dot gnu dot org 2008-07-14 06:57 --- Subject: Bug 36745 Author: krebbel Date: Mon Jul 14 06:56:46 2008 New Revision: 13 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=13 Log: 2008-07-14 Andreas Krebbel [EMAIL PROTECTED] PR target/36745 * config/s390/s390.c: (s390_secondary_reload): Add a secondary reload for symbol refs moved to r0 with -fPIC. (legitimize_pic_address): Use the target register as temporary reg if possible. (emit_symbolic_move): Adjust comment. * config/s390/s390.md (reloadsi_PIC_addr, reloaddi_PIC_addr): New expanders. 2008-07-14 Andreas Krebbel [EMAIL PROTECTED] PR target/36745 * g++.dg/torture/pr36745.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr36745.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/config/s390/s390.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36745
[Bug c/36818] unknow order to simple print
--- Comment #1 from schwab at suse dot de 2008-07-14 07:34 --- Order of evaluation is unspecified. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|unknow order to simple print|unknow order to simple print http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36818
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #13 from aaronavay62 at aaronwl dot com 2008-07-14 08:03 --- Joseph's patch doesn't work for me, because the --stack parameter never makes it to the link line for some reason, and I get the same crash building cipher.o. This is the relevant output of bootstrap: rm -f jc1.exe /mingw/src/gccf/./prev-gcc/xgcc -B/mingw/src/gccf/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -g -O2 -D__USE_MINGW_ACCESS -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 -o jc1.exe \ java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L../zlib -lz ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -L/mingw/src/gmp-mpfr/root/lib -L/mingw/src/gmp-mpfr/root/lib -lmpfr -lgmp I don't know if there is something particular to the way I've configured that might be making this break for me. As an additional data point, for some reason when I tried overriding LDFLAGS previously, the stack parameter also did not propagate properly to jc1.exe, although it propagated just fine to some of the other link lines outside of Java. ../svn/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp-mpfr/root --with-mpfr=/mingw/src/gmp-mpfr/root --with-libiconv-prefix=/mingw/src/libiconv/root make -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Last reconfirmed|2008-06-11 10:50:09 |2008-07-14 08:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug c++/36820] New: Exception can't be catched when --version-script is used
In my project, we have 3 components: test,libbar.so and libfoo.so. libbar.so
depends on libfoo.so,and test depends on the two .so. In libfoo.so, I throw an
exception, but libbar.so can't catch it.
exception.h--
#ifndef __EXCEPTION_H
#define __EXCEPTION_H
#include string
class ebase
{
public:
virtual std::string getmsg() =0;
};
class echild:public ebase
{
private:
std::string m_s;
public:
echild(const std::string s)
{
m_s=s;
}
virtual std::string getmsg()
{
return m_s;
}
};
#endif
--foo.cpp--
#include exception.h
void check_exception()
{
throw echild(check_insert: something happened);
}
--bar.cpp--
#include exception.h
#include foo.h
extern C void test()
{
try
{
check_exception();
}
catch(ebase e)
{
//exception should be catched here
printf(really good\n);
}
}
-test.cpp
#include foo.h
#include iostream
extern C void test();
int main()
{
test();
return 0;
}
--libbar.ver--
VERSION_1.0
{
global:
test;
local:
*;
};
--Makfile---
All:
g++ -g -shared -fPIC -c -o foo.o foo.cpp
g++ -g -shared -fPIC -c -o error.o error.cpp
g++ -g -shared -fPIC -o libfoo.so foo.o error.o
g++ -g -shared -fPIC -c -o bar.o bar.cpp
g++ -g -shared -fPIC -o libbar.so -Xlinker --version-script --Xlinker
./libbar.ver -L./ -lfoo bar.o
g++ -g -L. test.cpp -lbar -o test
clean:
rm libfoo.so libbar.so foo.o test
test() should print out really good, but it prints out unknown exception
instead.The output is:
terminate called after throwing an instance of 'echild'
Aborted
There are a lot of discussion about the exception defintion. Since all
defintion is in the .h file and all functions are inline functions, it may be a
problem.(See http://gcc.gnu.org/faq.html#vtables).
But if I don't use --version-script, nothing is wrong.Another workaround
solution is defining a non-inline virtual function for class ebase. So what the
hell is the real problem?
Thanks,
Alexi
--
Summary: Exception can't be catched when --version-script is used
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexi dot zuo at gmail dot com
GCC build triplet: X86 32bit Redhat Enterprise Linux AS release 4
GCC host triplet: X86 32bit Redhat Enterprise Linux AS release 4
GCC target triplet: X86 32bit Redhat Enterprise Linux AS release 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36820
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #8 from aaronavay62 at aaronwl dot com 2008-07-14 08:57 --- Eric, with that change, I see this: ../../../svn/libgcc/../gcc/libgcc2.c: In function '__do_global_ctors': ../../../svn/libgcc/../gcc/libgcc2.c:2161: internal compiler error: in i386_pe_binds_local_p, at config/i386/winnt.c:337 debug_tree(exp) var_decl 04C036E0 __CTOR_LIST__ type array_type 04C0EC98 type pointer_type 04C0EC30 func_ptr type function_type 03CC4888 public unsigned SI size integer_cst 03C987C0 constant 32 unit size integer_cst 03C98560 constant 4 align 32 symtab 79753888 alias set -1 canonical type 041F5D68 pointer_to_this pointer_type 04C0ED00 BLK align 32 symtab 0 alias set -1 canonical type 04C0EDD0 pointer_to_this pointer_type 04C12270 addressable used public external common BLK file ../../../svn/libgcc/../gcc/ gbl-ctors.h line 48 col 17 align 32 (mem/s/c:BLK (symbol_ref:SI (__CTOR_LIST__) var_decl 04C036E0 __CTOR_LIST __) [2 __CTOR_LIST__+0 A32]) chain var_decl 04C03738 __DTOR_LIST__ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug target/36613] [4.2/4.3/4.4 Regression] likely codegen bug
-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||07/msg00722.html Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-07-14 09:03 --- Eric, with that change, I see this: ../../../svn/libgcc/../gcc/libgcc2.c: In function '__do_global_ctors': ../../../svn/libgcc/../gcc/libgcc2.c:2161: internal compiler error: in i386_pe_binds_local_p, at config/i386/winnt.c:337 OK, thanks, the assertion is too broad. Could you replace it with gcc_assert (!(TREE_CODE (exp) == VAR_DECL TREE_STATIC (exp) DECL_EXTERNAL (exp))); instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #5 from paolo dot carlini at oracle dot com 2008-07-14 09:15 --- (In reply to comment #4) I think the first thing is to figure out what mangling we want for these things and if they should be mangled at all. The C++ ABI doesn't specify a mangling for these operators, since it doesn't specify these operators at all. They're really an implementation detail. So, the first question is Do these operators need to appear in mangled names at all? Is it a reasonable restriction on users to say thou shalt not use __is_empty in an expression that gets mangled? For example, can the user just use std::is_empty instead? Thanks for your feedback, Mark. Frankly, at the moment I don't have a strong opinion, but I'm wondering if existing practice can help us about those points: in fact such builtins are modeled after the existing Microsoft builtins: http://msdn.microsoft.com/de-de/library/ms177194.aspx and probably knowing what Microsoft is doing could help... However, I don't think Visual c++ uses our multivendor ABI, thus I'm not sure investigating that point could suggest a specific mangling. What do you think? (well, in case we are going to need help from people owning a recent Visual C++...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug fortran/36821] New: Flush denormals to Zero Flag
On current x86 and x86_64 processors denormal numbers are handled as a special case and very slowly. This can have a detrimental impact on the performance of numerical programs. A common fix for this problem, at the cost of some numerical stability, is to set the processor flag to flush denormals to zero. This can be achieved in C with the following on SSE machines: _MM_SET_FLUSH_ZERO_MODE (_MM_FLUSH_ZERO_ON); However it is not desirable to include C in a fortran program or library. Other compiler tackle this by adding flags (ifort, NAG f95) or environment variables (g95) which set this flush mode during program initialization. It would be good if gfortran offered a similar facility (I have not been able to locate any reference to one at the moment). -- Summary: Flush denormals to Zero Flag Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: J dot Hogg at rl dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821
[Bug fortran/36821] Flush denormals to Zero Flag
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-14 11:21 --- Compiling with -ffast-math will automatically do that at program startup time via linking against crtfastmath.o. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821
[Bug fortran/36821] Flush denormals to Zero Flag
--- Comment #2 from J dot Hogg at rl dot ac dot uk 2008-07-14 11:34 --- -ffast-math also enables other (even more unsafe?) optimizations which may not be desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36821
[Bug target/36822] New: [4.4 Regression] ICE in subst_reloads
s390x fails to build the linux kernel
./cc1 -quiet -O smp.3.i
Program received signal SIGSEGV, Segmentation fault.
0x008276f4 in subst_reloads (insn=0x7fc1f2451a00)
at /space/rguenther/src/svn/trunk/gcc/reload.c:6181
6181 gcc_assert (GET_CODE (*r-where) != LABEL_REF
(gdb) print *r-where
$1 = (rtx) 0x2b
testcase:
typedef unsigned char __u8;
typedef unsigned int __u32;
typedef unsigned long __u64;
struct _lowcore {
__u8 pad8[0xc00-0x2a0];
__u64 save_area[16];
__u8 pad9[0xd40-0xc80];
__u64 thread_info;
__u64 ext_call_fast;
__u8 pad13[0x1200-0xe04];
__u64 floating_pt_save_area[16];
__u64 gpregs_save_area[16];
__u32 st_status_fixed_logout[4];
__u32 access_regs_save_area[16];
__u64 cregs_save_area[16];
};
int __cpu_up(unsigned int cpu)
{
struct _lowcore *cpu_lowcore;
typedef struct {
char _[sizeof(cpu_lowcore-cregs_save_area[0])];
} addrtype;
asm volatile( stctg %2,%3,0(%1)\n
: =m (*(addrtype *)(cpu_lowcore-cregs_save_area[0]))
: a (cpu_lowcore-cregs_save_area[0]), i (0), i (15));
}
--
Summary: [4.4 Regression] ICE in subst_reloads
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390x-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36822
[Bug target/36822] [4.4 Regression] ICE in subst_reloads
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36822
[Bug target/31568] ICE with invalid %y operand (inline-asm)
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-14 12:43 ---
Testing this patch right now:
Index: testsuite/gcc.target/powerpc/asm-y.c
===
--- testsuite/gcc.target/powerpc/asm-y.c(revision 0)
+++ testsuite/gcc.target/powerpc/asm-y.c(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O1 } */
+
+/* Test that %yN does not cause an internal error if used incorrectly. */
+
+int f(int *a)
+{
+ asm (#%y0 : =m(a[2])); /* { dg-error try using the 'Z' constraint } */
+ asm (#%y0 : =m(a[1])); /* { dg-error try using the 'Z' constraint } */
+ asm (#%y0 : =m(a[0]));
+}
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c (revision 137784)
+++ config/rs6000/rs6000.c (working copy)
@@ -12288,9 +12288,13 @@ print_operand (FILE *file, rtx x, int co
fprintf (file, 0,%s, reg_names[REGNO (tmp)]);
else
{
- gcc_assert (GET_CODE (tmp) == PLUS
-REG_P (XEXP (tmp, 0))
-REG_P (XEXP (tmp, 1)));
+ if (!GET_CODE (tmp) == PLUS
+ || !REG_P (XEXP (tmp, 0))
+ || !REG_P (XEXP (tmp, 1)))
+ {
+ output_operand_lossage (invalid %%y value, try using the 'Z'
constraint);
+ break;
+ }
if (REGNO (XEXP (tmp, 0)) == 0)
fprintf (file, %s,%s, reg_names[ REGNO (XEXP (tmp, 1)) ],
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31568
[Bug middle-end/30142] [meta-bug] invalid gimple
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-14 12:44 --- I am no longer to fix this one, Guess nobody cares about the invalid gimple that is produced. Hopefully tuples fixes up most of these issues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia 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=30142
[Bug target/32107] bad codegen for vector initialization in Altivec
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-14 12:47 --- Note with the Cell, we can just use lvlx with a splat and that works without an alignment attribute on fa :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc-linux | GCC host triplet|powerpc-linux | GCC target triplet|powerpc-linux |powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32107
[Bug middle-end/36238] [4.4 Regression] ICE in reg_or_subregno, at jump.c:1730
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-14 12:57 --- Testing this on x86-darwin right now. though darwin's libfortran is broken so it might take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36238
[Bug rtl-optimization/36419] [4.3/4.4 Regression] Wrong unwind info with -Os -fasynchronous-unwind-tables
--- Comment #18 from jakub at gcc dot gnu dot org 2008-07-14 13:19 --- Created an attachment (id=15906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15906action=view) gcc44-pr36419.patch Patch I'm going to bootstrap/regtest now. It fixes the testcase. And to answer the last question, no, there is no code generation problem, only the unwind info (args_size in it) has been wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419
[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868
--- Comment #5 from jakub at gcc dot gnu dot org 2008-07-14 13:47 --- Subject: Bug 36745 Author: jakub Date: Mon Jul 14 13:46:25 2008 New Revision: 137785 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137785 Log: PR target/36745 * g++.dg/torture/pr36745.C: Use __SIZE_TYPE__ in size_t typedef. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr36745.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36745
[Bug c/36823] New: Fails to warn about possibly uninitialized variables
Target: i686-pc-linux-gnulibc2
Configured with: ../configure --prefix=/tmp/gcc-4.3.1 --disable-nls
--enable-shared --with-sysroot=/usr/i686-pc-linux-gnulibc2/
i686-pc-linux-gnulibc2
gcc version 4.3.1 (GCC)
$ gcc -O -Wall -Wuninitialized -c -o t.o t.c
$ gcc -O -Wall -Wuninitialized -fno-unit-at-a-time -c -o t.o t.c
t.c: In function 'f1':
t.c:14: warning: 'pp' may be used uninitialized in this function
$ cat t.c
struct a
{ struct a *n;
struct b *b;
};
struct b
{ struct b *n;
};
extern struct a *a;
static int
f1 (struct b *b)
{ struct b *pp;
struct b *p;
for (p = b; p; p = p-n) pp = p;
return (!pp);
}
int
f2 (void)
{ struct a *p;
for (p = a; p; p = p-n) if (f1 (p-b)) return 0;
return 1;
}
An older version of gcc (gcc (GCC) 3.3.3) works as expected.
A current version of gcc from Debian Unstable (gcc (Debian 4.3.1-6) 4.3.1)
shows the same failure
--
Summary: Fails to warn about possibly uninitialized variables
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heide-gcc at bfw-online dot de
GCC build triplet: i686-pc-linux-gnulibc2
GCC host triplet: i686-pc-linux-gnulibc2
GCC target triplet: i686-pc-linux-gnulibc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36823
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #10 from aaronavay62 at aaronwl dot com 2008-07-14 14:38 --- (In reply to comment #9) gcc_assert (!(TREE_CODE (exp) == VAR_DECL TREE_STATIC (exp) DECL_EXTERNAL (exp))); Eric, OK, now I get: /mingw/src/gccada/./prev-gcc/xgcc -B/mingw/src/gccada/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../svn/gcc/ada ../../svn/gcc/ada/a-except.adb -o ada/a-except.o +===GNAT BUG DETECTED==+ | 4.4.0 20080713 (experimental) (i386-pc-mingw32) GCC error: | | in i386_pe_binds_local_p, at config/i386/winnt.c:339 | | Error detected around ../../svn/gcc/ada\a-exexda.adb:647 | ... raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 debug_tree(exp) var_decl 03D11D68 system__soft_links__get_current_excep type pointer_type 03D142D8 system__soft_links__get_eoa_call type function_type 03D141A0 system__soft_links__T10s type pointer_type 038E5A90 ada__exceptions__exception_occurrence_access sizes-gimplified asm_written visited QI size integer_cst 000C8520 constant 8 unit size integer_cst 000C8540 constant 1 align 8 symtab 64062056 alias set -1 canonical type 03D141A0 arg-types tree_list 03D16DC0 value void_type 000DA7B8 void pointer_to_this pointer_type 03D142D8 system__soft_links__get_eoa_call sizes-gimplified visited unsigned SI size integer_cst 000C86E0 constant 32 unit size integer_cst 000C8480 constant 4 align 32 symtab 64062280 alias set -1 canonical type 03D142D8 side-effects addressable volatile public static unsigned external SI file ../../svn/gcc/ada\s-soflin.ads line 255 col 4 size integer_cst 000C86E0 32 unit size integer_cst 000C8480 4 align 32 (mem/v/f/c/i:SI (symbol_ref:SI (system__soft_links__get_current_excep) var_decl 03D11D68 system__soft_links__get_current_excep) [0 system__soft_links__get_current_excep+0 S4 A32]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-07-14 14:44 --- /mingw/src/gccada/./prev-gcc/xgcc -B/mingw/src/gccada/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../svn/gcc/ada ../../svn/gcc/ada/a-except.adb -o ada/a-except.o +===GNAT BUG DETECTED==+ | 4.4.0 20080713 (experimental) (i386-pc-mingw32) GCC error: | | in i386_pe_binds_local_p, at config/i386/winnt.c:339 | | Error detected around ../../svn/gcc/ada\a-exexda.adb:647 | Thanks. We have identified the potential source of the problem in Gigi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #6 from sebor at roguewave dot com 2008-07-14 15:24 --- (In reply to comment #4) ... Is it a reasonable restriction on users to say thou shalt not use __is_empty in an expression that gets mangled? For example, can the user just use std::is_empty instead? As a data point, consider that the user may be an author of a third party implementation of the C++ standard library (such as Apache/Rogue Wave or STLport), and they may not be able to use std::is_empty for reasons unique to their project (e.g., policy or otherwise). My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #7 from mark at codesourcery dot com 2008-07-14 15:28 --- Subject: Re: ICE on SFINAE and __is_empty sebor at roguewave dot com wrote: My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). How does it mangle it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #8 from sebor at roguewave dot com 2008-07-14 15:41 --- (In reply to comment #7) Subject: Re: ICE on SFINAE and __is_empty sebor at roguewave dot com wrote: My preference would be for gcc to avoid imposing restrictions on the use of these helpers to facilitate portability to other compilers such as EDG eccp (the latest 3.10.1 compiles the test case correctly). How does it mangle it? Like so: int fooA0 (BA0, __is_empty (A0)::X*): _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE int fooint(Bint, !__is_empty (int)::X*): _Z3fooIiEiPN1BIT_Xntv19builtin16TOS1_EE1XE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug fortran/36824] New: gfortran does not recognize constant array bounds in dimension attribute of type component
- program test implicit none integer, dimension( 3 ), parameter :: tgc = (/5, 6, 7 /) type tgccomp integer, dimension( tgc( 1 ) : tgc( 2 ) ) :: tgclist end type tgccomp end program - This gives the following error: gfortran test.f90 test.f90:8.73: integer, dimension( tgc( 1 ) : tgc( 2 ) ) :: tgclist 1 Error: Component 'tgclist' of 'tgccomp' at (1) must have constant array bounds This works: - type tgccomp integer, dimension( 1 : tgc( 1 ) ) :: tgclist end type tgccomp - -- Summary: gfortran does not recognize constant array bounds in dimension attribute of type component Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: flad at gmx dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36824
[Bug bootstrap/18895] libgfortran AM_MAKEFLAGS arg list + environment too large
--- Comment #6 from bonzini at gnu dot org 2008-07-14 16:03 --- any news? also, P1 is probably wrong (resetting to P3). -- bonzini at gnu dot org changed: What|Removed |Added Status|REOPENED|WAITING Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18895
[Bug rtl-optimization/35281] [4.3 Regression] multiply with 0 generated for 64*32-64
--- Comment #18 from bonzini at gnu dot org 2008-07-14 16:07 --- The two commits listed here fix the regression, they should be safe to backport to 4.3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #8 from bonzini at gnu dot org 2008-07-14 16:18 --- mine -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-08 13:23:39 |2008-07-14 16:18:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #9 from bonzini at gnu dot org 2008-07-14 16:29 --- In fact, using modified_between_p would not fix the bug. The problem is that use_killed_between gives the wrong answer *before* it reaches the code that redoes modified_between_p using df data structures. I'll regtest this patch tomorrow because the machine is right now too busy. But if anyone wants to beat me, feel free. Index: ../../peak-gcc-src/gcc/fwprop.c === --- ../../peak-gcc-src/gcc/fwprop.c (revision 136756) +++ ../../peak-gcc-src/gcc/fwprop.c (working copy) @@ -480,10 +480,15 @@ use_killed_between (struct df_ref *use, return true; /* Check if the reg in USE has only one definition. We already - know that this definition reaches use, or we wouldn't be here. */ + know that this definition reaches use, or we wouldn't be here. + However, this is not true for hard registers, because if they are + live at the beginning of the function it does not mean that we + have an uninitialized access. */ regno = DF_REF_REGNO (use); def = DF_REG_DEF_CHAIN (regno); - if (def (def-next_reg == NULL)) + if (def + (def-next_reg == NULL) + regno = FIRST_PSEUDO_REGISTER) return false; /* Check locally if we are in the same basic block. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #9 from mark at codesourcery dot com 2008-07-14 16:53 --- Subject: Re: ICE on SFINAE and __is_empty sebor at roguewave dot com wrote: int fooA0 (BA0, __is_empty (A0)::X*): _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE int fooint(Bint, !__is_empty (int)::X*): _Z3fooIiEiPN1BIT_Xntv19builtin16TOS1_EE1XE OK. I don't see anything inherently wrong with that mangling, though of course if we're going to make this standard, we need EDG's table of builtins (so we known which ones are which), and we need to specify semantics for each of the builtins so that we know that we can mix object files between different compilers. (No good if G++'s __is_empty is somehow subtly different than EDG's __is_empty.) So, I think the high-order issues here are still: (1) Do we need a mangling? (I know you think we do.) (2) If so, do we want to specify it at the ABI level, or use something G++-specific? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c/23104] [4.2/4.3/4.4 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #12 from nightstrike at gmail dot com 2008-07-14 17:09 ---
On 4.2.4 and 4.3.1, I get this:
$ cat a.c
int f(void) {}
$ cat b.c
int f(void) {}
$ /opt/cfarm/release/4.3.1/bin/gcc -combine a.c b.c
a.c:2: error: redefinition of 'f'
a.c:1: error: previous definition of 'f' was here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug fortran/36825] New: Problems with dimensions 7
gfortran 4.4 allows 15 instead of 7 dimensions, however, it has some problems with that: gfortran -std=f95 -Wall -pedantic should print a message for: integer,parameter:: N=10 complex,dimension(-N:N,-N:N,0:1,0:1,-N:N,-N:N,0:1,0:1) :: P end But it does not. This seems to be an off-by-one error as for 9 dimensions an error is printed: Error: Fortran 2008: Array specification at (1) with more than 7 dimensions * * * More seriously, adding a PRINT causes an IDE: a.f90:1: internal compiler error: in gfc_get_dtype, at fortran/trans-types.c:1254 integer,parameter:: N=10 complex,dimension(-N:N,-N:N,0:1,0:1,-N:N,-N:N,0:1,0:1) :: P print *, p end -- Summary: Problems with dimensions 7 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, diagnostic 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=36825
[Bug fortran/36825] Problems with dimensions 7
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-14 17:28 --- The I/O ICE is due to: trans-types.c: gcc_assert (rank = GFC_DTYPE_RANK_MASK); where the maximal DTYPE rank is defined as: libgfortran.h:#define GFC_DTYPE_RANK_MASK 0x07 The other problem can be cured using: Index: array.c === --- array.c (Revision 137756) +++ array.c (Arbeitskopie) @@ -437,7 +437,7 @@ gfc_match_array_spec (gfc_array_spec **a goto cleanup; } - if (as-rank 7 + if (as-rank = 7 gfc_notify_std (GFC_STD_F2008, Fortran 2008: Array specification at %C with more than 7 dimensions) == FAILURE) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug other/36820] Exception can't be catched when --version-script is used
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-14 18:43 --- I don't think this is a bug as the typeinfo of ebase in libbar is being marked as hidden (local) so you have two different typeinfo that are not merged at load time. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c++ |other GCC build triplet|X86 32bit Redhat Enterprise | |Linux AS release 4 | GCC host triplet|X86 32bit Redhat Enterprise | |Linux AS release 4 | GCC target triplet|X86 32bit Redhat Enterprise |i686-pc-linux-gnu |Linux AS release 4 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36820
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #10 from sebor at roguewave dot com 2008-07-14 18:43 --- (In reply to comment #9) I'd be happy to provide whatever info you need (e.g., the table of built-ins, if you can explain to me how to get it from the front-end :) As for the semantics of the built-ins, I assume both EDG and gcc used Howard Hinnant's Compiler Support for type_traits as the starting point: http://home.twcny.rr.com/hinnant/cpp_extensions/cpp_extensions AFAICS, the built-ins aren't document in any detail in the EDG eccp manual. Finally, if you intend to provide ABI compatibility with the EDG eccp front end (or vice versa) I'd suggest getting someone from EDG involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug ada/15479] Ada manual problems
--- Comment #12 from rwild at gcc dot gnu dot org 2008-07-14 18:50 ---
Subject: Bug 15479
Author: rwild
Date: Mon Jul 14 18:49:37 2008
New Revision: 137793
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137793
Log:
gcc/ada/
PR documentation/15479
* gnat_ugn.texi (@ovar): New macro, from autoconf.texi.
Replace backets around optional parameters with @ovar
where possible, use @r{[}, @r{]} otherwise.
Replace some @r, @i, and @emph with @var where appropriate.
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_ugn.texi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15479
[Bug fortran/36824] gfortran does not recognize constant array bounds in dimension attribute of type component
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-14 19:30 ---
The following seems to fix it.
Index: resolve.c
===
--- resolve.c (Revision 137789)
+++ resolve.c (Arbeitskopie)
@@ -7682,8 +7805,8 @@ resolve_fl_derived (gfc_symbol *sym)
for (i = 0; i c-as-rank; i++)
{
if (c-as-lower[i] == NULL
- || !gfc_is_constant_expr (c-as-lower[i])
|| (resolve_index_expr (c-as-lower[i]) == FAILURE)
+ || !gfc_is_constant_expr (c-as-lower[i])
|| c-as-upper[i] == NULL
|| (resolve_index_expr (c-as-upper[i]) == FAILURE)
|| !gfc_is_constant_expr (c-as-upper[i]))
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36824
[Bug c++/36826] New: ICE in fold_convert, at fold-const.c:2528
$gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080714 (experimental) (GCC) Running g++ -O3 -fomit-frame-pointer -pipe -pedantic-errors -Wall -MD -MP -c -fPIC -DPIC -o ClpSimplex.o ClpSimplex.i on the soon-to-be attached file I get: ClpSimplex.cpp: In member function 'void ClpSimplex::deleteRim(int)': ClpSimplex.cpp:4325: internal compiler error: in fold_convert, at fold-const.c:2528 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in fold_convert, at fold-const.c:2528 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36826
[Bug middle-end/36826] ICE in fold_convert, at fold-const.c:2528
--- Comment #1 from sdirkse at gams dot com 2008-07-14 20:18 --- Created an attachment (id=15907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15907action=view) zipped, pre-processed source to turf up the bug I couldn't generate the .i file using -save-temps, so I used -E instead. Is that also a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36826
[Bug middle-end/36826] ICE in fold_convert, at fold-const.c:2528
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-14 20:20 --- (In reply to comment #1) I couldn't generate the .i file using -save-temps, so I used -E instead. Is that also a bug? Most likely not as it is going to be a .ii file as it is C++ :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36826
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #1 from brtnfld at hdfgroup dot org 2008-07-14 20:45 --- For the simple program, PROGRAM main USE ISO_C_BINDING CHARACTER(LEN=2, KIND=C_CHAR), TARGET :: chr TYPE(C_PTR) :: chr_ptr chr_ptr = C_LOC(chr) END PROGRAM main the work around is to: CHARACTER(LEN=1, KIND=C_CHAR), dimension(1:2), TARGET :: chr However, forcing it to be an array instead of a character(LEN1) causes problems with generic interfaces. Take for example the following code which to me looks to be standard compliant, via the standard the CHARACTER(LEN=4) actual argument is allowed to match a CHARACTER(LEN=1,KIND=C_CHAR), DIMENSION(4) dummy argument (12.4.1.2). But the compiler will not recognize subroutine 'Two' as a valid interface for the call indicated since the dimensions check is not satisfied even though it is a valid interface. So if you are going by the standard you can not use a generic interface to handle a scalar character (len1) and an array of characters (keeping in mind that all the subroutines have to have LEN=1 so that you can use C_LOC). MODULE modtest USE ISO_C_BINDING INTERFACE One MODULE PROCEDURE Two END INTERFACE CONTAINS SUBROUTINE Two( chr ) CHARACTER(LEN=1, KIND=C_CHAR), DIMENSION(1:4) :: chr END SUBROUTINE Two END MODULE modtest PROGRAM main USE ISO_C_BINDING USE modtest CHARACTER(LEN=4, KIND=C_CHAR) :: chrScalar chrScalar = 'Scal' ! This does not work, it will not find the interface. CALL One( chrScalar ) ! This works CALL Two( chrScalar ) END PROGRAM main It is simply not feasible to cast all character strings into character arrays. This problem would all go away if we did not have to recast the string as an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug tree-optimization/36788] [4.4 Regression] ICE in loop_optimizer_init at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36788
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-07-14 21:50 --- OK, thanks for the tip. The patch to convert Ada to a canonical boolean type is written though (and eliminates the ICE as expected), I'm just waiting for the GDB people to adjust the Ada module. This will be further delayed, the Ada compiler has been in poor shape for a week and I'll be away for some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug c/36827] New: newlib:libm/math/k_rem_pio2.c fails in reload
as of rev 137639:
cc1 -fpreprocessed k_rem_pio2.i -quiet -dumpbase k_rem_pio2.c -auxbase-strip
lib_a-k_rem_pio2.o -Os -fno-builtin -o k_rem_pio2.s
src/newlib/libm/math/k_rem_pio2.c: In function '__kernel_rem_pio2':
newlib/libm/math/k_rem_pio2.c:318: error: unable to find a register to spill in
class 'A_REGS'
newlib/libm/math/k_rem_pio2.c:318: error: this is the insn:
(jump_insn 1098 1096 2868 9 newlib/libm/math/k_rem_pio2.c:186 (set (pc)
(if_then_else (gt (subreg:HI (reg/v:SI 1108 [ i ]) 2)
(subreg:HI (reg/v:SI 1105 [ m ]) 2))
(label_ref:HI 3007)
(pc))) 48 {cbranchhi4} (expr_list:REG_BR_PROB (const_int 5000
[0x1388])
(nil)))
newlib/libm/math/k_rem_pio2.c:318: internal compiler error: in spill_failure,
at reload1.c:1995
--
Summary: newlib:libm/math/k_rem_pio2.c fails in reload
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dj at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug c/36827] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #1 from dj at redhat dot com 2008-07-14 22:31 --- Created an attachment (id=15908) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15908action=view) preprocessed file for description -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug target/36827] [4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target Summary|newlib:libm/math/k_rem_pio2.|[4.4 Regression] |c fails in reload |newlib:libm/math/k_rem_pio2. ||c fails in reload Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug target/36827] [4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-07-14 22:44 --- Note that the problematic patch has been installed on the 4.3 branch as well. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||build Target Milestone|4.4.0 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug c/36828] New: 4.3.1 when optimising for size generates much larger code than 4.0.x
The attached C file generates a significantly larger object code with the new compiler than with the old one. The exact command line for gcc is in the first comment of the C file. -- Summary: 4.3.1 when optimising for size generates much larger code than 4.0.x Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zoltan at bendor dot com dot au GCC build triplet: x86-elf-linux GCC host triplet: x86-elf-linux GCC target triplet: arm-elf-unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36828
[Bug objc++/36723] [4.4 Regression] massive obj-c++ failures at rev.137407
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-07-15 00:59 --- Also occurs on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01321.html http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01323.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2008-07-08 22:39:54 |2008-07-15 00:59:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36723
[Bug bootstrap/36664] [4.4 Regression] bootstrap failure at rev.137248
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-07-15 01:06 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at caip dot rutgers |ghazi at gcc dot gnu dot org |dot edu | Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36664
[Bug target/36829] New: Take advantage of lower bit zeroing of load/store insns on SPU
The SPU's load and store instructions ({l,st}q{a,d,r,x}) zero the lower four
bits of the computed address before performing the requested load or store. In
certain cases (particularly, working with array loads of vector data), this may
be utilised to avoid unnecessary shifts and masks.
Consider rottest.c:
#include spu_intrinsics.h
vector unsigned int a[1024];
vector unsigned int f(int i) {
return a[iROTN];
}
Compiled with spu-elf-gcc rottest.c -c -S -O3 -DROTN=8 :
(Using gcc 4.4.0 20080404)
f:
rotmai $4,$3,-8
ila $2,a
shli$3,$4,4
lqx $3,$2,$3
bi $lr
The rotmai and shli may be legitimately combined to yield something like:
f:
rotmai $4,$3,-4
ila $2,a
lqx $3,$2,$3
bi $lr
Compiled with spu-elf-gcc rottest.c -c -S -O3 -DROTN=4 :
f:
ila $2,a
andi$3,$3,-16
lqx $3,$2,$3
bi $lr
The andi is redundant.
--
Summary: Take advantage of lower bit zeroing of load/store insns
on SPU
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jadamcze at utas dot edu dot au
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36829
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #5 from jifl-bugzilla at jifvik dot org 2008-07-15 01:19 --- Created an attachment (id=15909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15909action=view) Patch against 4.3.1 using a once variable to ensure safe initialisation Here's a patch, let me know what you think. As a bonus, I've added a fix for a thinko in concurrence.h with initialising a condition variable. 2008-07-14 Jonathan Larmour [EMAIL PROTECTED] PR libstdc++/36801 * include/ext/concurrence.h: Separate out __mutex construction into a separate public method. Fix __gthread_cond_t initialisation function macro name. * config/cpu/generic/atomicity_mutex/atomicity.h: In a threaded environment, use a once variable to guarantee atomic_mutex is initialised before use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug tree-optimization/36830] New: [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/ -B/opt/g nu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/ -c -g -O2 -mdisable-indexing -gn atpg -gnata -gnatwns -nostdinc -I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/a da/s-os_lib.adb -o ada/s-os_lib.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[3]: *** [ada/s-os_lib.o] Error 1 This was introduced in revision 137631. So far, I haven't found a way to debug this error. The error doesn't occur when I run the compile under gdb, or when I enable the private mapping of shared libraries. Somehow, the code is attempting to write somewhere in the region of memory occupied by libc. gdb doesn't let me run programs without mapping shared libraries as private. Still present in revision 137803. -- Summary: [4.4 Regression] STORAGE_ERROR raised compiling s- os_lib.adb Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830
[Bug middle-end/35736] [4.4 regression] ICE with continue and -Wall
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-07-15 04:15 --- Fixed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35736
[Bug objc++/36723] [4.4 Regression] massive obj-c++ failures at rev.137407
--- Comment #4 from jason at gcc dot gnu dot org 2008-07-15 05:12 --- Subject: Bug 36723 Author: jason Date: Tue Jul 15 05:11:18 2008 New Revision: 137813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137813 Log: PR objc++/36723 * objc/objc-act.c (objc_build_constructor): Update C++ tweak. * cp/lex.c (init_reswords): Always set D_OBJC. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lex.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36723
[Bug objc++/36723] [4.4 Regression] massive obj-c++ failures at rev.137407
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-15 00:59:56 |2008-07-15 05:12:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36723
[Bug objc++/36723] [4.4 Regression] massive obj-c++ failures at rev.137407
--- Comment #5 from jason at gcc dot gnu dot org 2008-07-15 05:12 --- fixed -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36723
