[Bug middle-end/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-13 08:24:40 UTC --- Well, the expander - or rather the constant should be properly extended in the first place (if it is signed).
[Bug ada/49724] [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49724 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug ada/49725] [4.6 Regression] FAIL: c34005a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49725 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-13 08:26:09 UTC --- Does it work on trunk then?
[Bug c++/49727] New: Same classes in different files issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49727
Summary: Same classes in different files issue.
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ho...@ukr.net
We have 2 classes with the same name in different files. They both are in one
namespace.
1 class is in .cpp file and another in .h. Using of objects is not intercepts
in different modules.
ex: foo.h contains : namespace A{ class A{}; }, bar.cpp contains: namespace A{
class A{}; }
While running program it is crashed because of use wrong class in foo.cpp in
our case.
[Bug c++/49728] New: g++ - int object in memory deleted multiple times: no runtime error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49728
Summary: g++ - int object in memory deleted multiple times: no
runtime error
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b7756...@klzlk.com
Created attachment 24749
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24749
source code
Hi!
Below is an example, where an int-memory-object is deleted 3 times.
No runtime errors occur?
Is this a bug?
Thanks.
The example uses smart-pointers.
(source sode attached)
The int-memory-object (pointed-to by ip) is deleted 3 times: see lines 59, 62,
67
The deleted int-memory-object, can still be accessed: see lines 61, 64, 68
// line 1
// Below an int-object is created with new int(1)
// Usually a runtime error occurs if an object is deleted 2 or more times.
// But in the course of the execution, the object is deleted 3 times -- Why
does no runtime error occur?
#include iostream
using std::cout;
using std::endl;
class U_a
{
friend class B;
U_a(int *p) : ip(p), use(1) {}
~U_a() {
std::cout Delete ip std::endl;
delete ip;
}
int *ip;
size_t use; // use-counter, used by smart-pointer...
};
class B // uses smart pointers
{
public:
B(int *p) : ptr(new U_a(p)) {}
B(const B rhs) : ptr(rhs.ptr) {
++ptr-use;
}
B operator=(const B rhs) {
++rhs.ptr-use;
if (--ptr-use == 0)
delete ptr;
ptr = rhs.ptr;
return *this;
}
int get_ip_val() {
return *ptr-ip;
}
~B() {
if (--ptr-use == 0)
delete ptr;
}
private:
U_a *ptr;
};
int main()
{
int *ip = new int(1); // created object-pointed-to-by ip and give it
initial value 1
{
B b1(ip);
{
B b2(ip); // deliberate bad use of smart-pointer class. This is
not the copy constructor! ;)
cout Val: b1.get_ip_val() endl;
} // b2's destructor has run and deleted
object-pointed-to-by ip!
cout Val: b1.get_ip_val() endl; // 1)*** Why can we still get
object-pointed-to-by ip? Why is there no runtime error?
} // 2)*** b1's destructor has run and deleted object-pointed-to-by
ip the second time!!! Why is there still no runtime error?
*ip = 4; // 3)*** Why is there still no runtime error?
std::cout Delete ip std::endl;
delete ip; // here we delete object-pointed-to-by ip a 3rd time 4)***
Why is there still no runtime error?
*ip = 5; // 5)*** Why is there still no runtime error?
return 0;
}
[Bug c++/49728] g++ - int object in memory deleted multiple times: no runtime error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49728 --- Comment #1 from JohnBrystone b7756204 at klzlk dot com 2011-07-13 08:56:00 UTC --- posted here first... http://www.cplusplus.com/forum/general/46599/
[Bug c++/49727] Same classes in different files issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49727 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-13 09:14:13 UTC --- That is a clear ODR violation.
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.13 09:20:38 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-07-13 09:20:38 UTC --- Created attachment 24750 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24750 proposed patch This patch seems to do it for me. It took me some time due to several false starts. Unfortunately, with gld instead of Sun ld, you don't see the problem. Since I could only run the bootstrap on a Solaris 8 branded zone where the default libthread.so is a copy of the lwp one, could you try it on bare metal to confirm that it works? I'll backport to 4.6 once this is on mainline. Thanks. Rainer
[Bug c++/49729] New: diagnostic cascade
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49729
Summary: diagnostic cascade
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: igod...@pacbell.net
This code:
int main() {
for(int i = 0; i 10; ++i)
continue);
return 0;
}
got me:
s3:~/ootbc/sim$ g++ foo.cc
foo.cc: In function ‘int main()’:
foo.cc:3: error: expected ‘;’ before ‘)’ token
foo.cc:3: error: expected primary-expression before ‘)’ token
foo.cc:3: error: expected ‘;’ before ‘)’ token
I got the idea the first time :-)
[Bug fortran/25829] [F2003] Asynchronous IO support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-13 09:24:40 UTC --- Note: TR 29113 introduces a wider coverage of ASYNCHRONOUS, cf. almost-PDTR 29113 at ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1866.pdf. I think the easiest is to not set the restrict of dummy arguments involved in ASYNCHRONOUS I/O. That way, one has: call user_write(id, var) ... call user_wait(id) var = ... The address of the var escapes at user_write and is thus available to user_wait - hence, var = will not be moved across user_wait. Ditto for gfortran's asynchronous I/O.
[Bug c++/49729] diagnostic cascade
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49729 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.13 09:34:44 Ever Confirmed|0 |1 Known to fail||4.1.2, 4.4.3, 4.5.2, 4.6.1, ||4.7.0 Severity|normal |minor --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-13 09:34:44 UTC --- confirmed
[Bug c++/49728] g++ - double free - int object in memory deleted multiple times: no runtime error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49728 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-13 09:38:45 UTC --- You haven't provided most of the information requested at http://gcc.gnu.org/bugs/ The code has undefined behaviour, that doesn't mean you get an error, it means the code is buggy. It's not the compiler's job to diagnose it. On GNU/Linux use valgrind or glibc's MALLOC_CHECK_ feature (see 'man malloc')
[Bug middle-end/49719] [4.7 Regression] test gcc.target/arm/sibcall-1.c fails for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49719 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.13 09:45:43 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 09:45:43 UTC --- The sibcall still works on x86 but is indeed disabled on ARM because of the lack of [reg+disp] addressing mode. While on x86 you have: (insn 15 14 16 3 (set (reg:SI 67) (mem/s/c:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) (const_int 32 [0x20])) [3 a+8 S4 A32])) sibcall-1.c:22 -1 (nil)) (insn 16 15 17 3 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args) (const_int 16 [0x10])) [0 S4 A32]) (reg:SI 67)) sibcall-1.c:22 -1 (nil)) on ARM you have instead: (insn 21 10 22 3 (set (reg:SI 143) (reg/f:SI 131 virtual-outgoing-args)) sibcall-1.c:22 -1 (nil)) (insn 22 21 23 3 (set (reg:SI 144) (plus:SI (reg/f:SI 128 virtual-incoming-args) (const_int 16 [0x10]))) sibcall-1.c:22 -1 (nil)) (insn 23 22 24 3 (parallel [ (set (reg:SI 0 r0) (mem/s/c:SI (reg:SI 144) [3 a+8 S4 A32])) (set (reg:SI 1 r1) (mem/s/c:SI (plus:SI (reg:SI 144) (const_int 4 [0x4])) [3 a+12 S4 A32])) ]) sibcall-1.c:22 -1 (nil)) (insn 24 23 25 3 (parallel [ (set (mem:SI (reg:SI 143) [0 S4 A32]) (reg:SI 0 r0)) (set (mem:SI (plus:SI (reg:SI 143) (const_int 4 [0x4])) [0 S4 A32]) (reg:SI 1 r1)) ]) sibcall-1.c:22 -1 (nil)) so mem_overlaps_already_clobbered_arg_p doesn't see the displacement in the effective address of the load. Quite annoying.
[Bug c++/49728] g++ - double free - int object in memory deleted multiple times: no runtime error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49728 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-13 09:47:14 UTC --- See http://blog.regehr.org/archives/213 for an introduction to what undefined behaviour means. C++ does not check for runtime errors, instead your program is simply broken. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html is another good article.
[Bug tree-optimization/49580] SPEC2006 GCC benchmark build failure when run with autopar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49580
--- Comment #1 from razya at il dot ibm.com 2011-07-13 10:20:08 UTC ---
(In reply to comment #0)
Compilation of reload1.c fails:
gcc -c -o reload1.o -DSPEC_CPU -DNDEBUG -I. -fpeel-loops -funroll-loops
-fno-tree-vectorize -fno-vect-cost-model -fdump-tree-vect-details
-ftree-parallelize-loops=8 -fdump-tree-parloops-details -O3
-falign-functions=16 -falign-loops=32 -m64 -ffast-math -O3 -mrecip=rsqrt
-fpeel-loops -funroll-loops -fno-tree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details -ftree-parallelize-loops=8
-fdump-tree-parloops-details -greload1.c
reload1.c: In function ‘forget_old_reloads_1’:
reload1.c:4095:1: internal compiler error: in gsi_insert_seq_nodes_after, at
gimple-iterator.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The failure happens while parallellizing, in gimple_duplicate_sese_tail():
new_rhs = fold_build2 (MINUS_EXPR, TREE_TYPE (gimple_cond_rhs
(cond_stmt)),
gimple_cond_rhs (cond_stmt),
build_int_cst (TREE_TYPE (gimple_cond_rhs
(cond_stmt)), 1));
if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
{
iters_bb = gimple_bb (SSA_NAME_DEF_STMT (gimple_cond_rhs
(cond_stmt)));
for (gsi1 = gsi_start_bb (iters_bb); !gsi_end_p (gsi1); gsi_next
(gsi1))
if (gsi_stmt (gsi1) == SSA_NAME_DEF_STMT (gimple_cond_rhs
(cond_stmt)))
break;
new_rhs = force_gimple_operand_gsi (gsi1, new_rhs, true,
NULL_TREE,false,GSI_CONTINUE_LINKING);
}
In this case, iters_bb contains the defining stmt for
gimple_cond_rhs (cond_stmt), which is a gimple_phi stmt.
Therefore, iterating the stmts of iters_bb will not find the defining stmt
and the iterator for force_gimple_operand_gsi (gsi1, new_rhs, true,...)
will be NULL.
One solution could be to check whether the defining stmt is a gimple_phi stmt,
and handle that correctly.
However, there's one other case that is still not covered, that is if the
definition
of gimple_cond_rhs (cond_stmt) is default_def (in which case iters_bb will be
NULL causing segmentation fault)
Instead of covering these two missing cases, it seems simpler and more elegant
to insert the stmt generated by force_gimple_operand_gsi (gsi1, new_rhs,
true..) to the loop's preheader instead of inserting ti to iters_bb (the RHS
of
the cond stmt is already defined before entering the loop, therefore can be
changed at the preheader)
Please assign this bug to me.
Thank you.
Committed this fix:
http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00115.html
gcc benchmark builds and runs successfully.
Razya
[Bug tree-optimization/49580] SPEC2006 GCC benchmark build failure when run with autopar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49580 razya at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from razya at il dot ibm.com 2011-07-13 10:21:20 UTC --- patch committed: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00115.html
[Bug middle-end/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.13 10:34:54 Ever Confirmed|0 |1 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 10:34:54 UTC --- Indeed, (const_int 2147483648 [0x8000]) isn't valid for SImode, it should be (const_int -2147483648 [0x8000]) as RTL constants are always sign-extended for their mode. Usually a GEN_INT used in lieu of gen_int_mode.
[Bug tree-optimization/49730] New: loop not vectorized if inside another loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49730
Summary: loop not vectorized if inside another loop
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
I've this simple double loop (used in benchmark)
the inner loop (sloop) is not vectorized when invoked inside the longer loop
(dloop)
c++ -Ofast -c vectdloop.cc -ftree-vectorizer-verbose=7
vectdloop.cc:9: note: Profitability threshold = 6
vectdloop.cc:9: note: Profitability threshold is 6 loop iterations.
vectdloop.cc:9: note: LOOP VECTORIZED.
vectdloop.cc:7: note: vectorized 1 loops in function.
vectdloop.cc:20: note: not vectorized: unexpected loop form.
vectdloop.cc:16: note: vectorized 0 loops in function.
#includecmath
inline float fn(float x) {
return 2.f*x+std::sqrt(x);
}
void sloop(float * __restrict__ s, float const * __restrict__ xx) {
const int ls=16;
for (int j=0; j ls; ++j) {
s[j] = fn(xx[j]);
}
}
int dloop(float yyy) {
int niter = 10;
float x = 0.5f; yyy=0;
const int ls=16;
for (int i=0; i niter; ++i) {
float s[ls]; float xx[ls];
for (int j=0; j ls; ++j) xx[j] =x+(5*(j1));
sloop(s,xx);
// for (int j=0; j ls; ++j) s[j] = fn(xx[j]);
x += 1e-6f;
for (int j=0; j ls; ++j) yyy+=s[j];
}
if (yyy == 2.32132323232f) niter--;
return niter;
}
[Bug middle-end/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 10:49:16 UTC --- Indeed, (const_int 2147483648 [0x8000]) isn't valid for SImode, it should be (const_int -2147483648 [0x8000]) as RTL constants are always sign-extended for their mode. Actually (const_int -2147483648 [0x8000]) on a 64-bit host.
[Bug tree-optimization/49730] loop not vectorized if inside another loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49730 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011.07.13 11:23:16 CC||irar at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-13 11:23:16 UTC --- All inner loops are simply completely unrolled which eliminates the s array. Then we end up with a loop with two reductions which cannot be vectorized right now.
[Bug target/49487] Internal compiler error in AVR code (bytewise rotate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug tree-optimization/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-13
12:31:13 UTC ---
Further reduced (-O2 vs. -O1):
#include vector
#include algorithm
extern C void abort (void);
typedef unsigned int u32;
using namespace std;
vectoru32 g;
void f(u32 b)
{
g.push_back(b);
for(int i=1; ig.size() ! g.empty(); ++i)
if ( g[i-1]+1 != g[i])
abort ();
}
int main(int argc, char *argv[])
{
u32 a = 0;
vectorint vi;
vi.push_back(0);
vectorint ve;
ve.push_back(5);
vectorint v7;
auto run = [](int i) {
v7.push_back(i);
f(a++);
};
for_each(vi.begin(), vi.end(), [](int xi) {
f(a++);
for_each(ve.begin(), ve.end(), run);
f(a++);
for_each(ve.begin(), ve.end(), run);
});
}
[Bug middle-end/49731] New: internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49731
Summary: internal compiler error: verify_gimple failed
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
[hjl@gnu-6 tests]$ cat foo.c
void g_hash_table_insert (void *, void*);
void int64_hash_test ()
{
int i;
long long values[4];
for (i=0; i4; i++)
{
values[i] = i + 42;
g_hash_table_insert (values[i], ((void *) (i + 42)));
}
}
[hjl@gnu-6 tests]$ /usr/gcc-4.7.0-x32/bin/x86_64-unknown-linux-gnu-gcc -O2
-mx32 -S foo.c
foo.c: In function \u2018int64_hash_test\u2019:
foo.c:2:6: error: invalid types in nop conversion
void *
long long unsigned int
D.2730_20 = (void *) ivtmp.14_13;
foo.c:2:6: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-6 tests]$
[Bug ada/49732] New: GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49732 Summary: GNAT 4.6.[01] crashes on terminal_interface-curses-menus.adb from ncruses 5.9 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: vorfeed.ca...@gmail.com This is Linux (I've tried both i686 and x86-64). GCC was compiled with the following options: /localbuild/src/sysnative-pregcc-4.6.1/gcc-4.6.1/configure --with-gmp=/localbuild/install/sysnative-pregcc-4.6.1/gmp-5.0.2 --with-mpfr=/localbuild/install/sysnative-pregcc-4.6.1/mpfr-3.0.1 --with-mpc=/localbuild/install/sysnative-pregcc-4.6.1/mpc-0.9 --enable-symvers=gnu-versioned-namespace --enable-cloog-backend=isl --enable-threads --enable-tls --enable-languages=ada,c,c++ --prefix=/sysnative --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu I'm not sure what command line was issued to call the GCC but from ncurses 5.9 compilation log: gnatmake -P/localbuild/src/sysnative-prencurses-5.9/Ada95/src/library.gpr -XBUILD_DIR=`cd ..;pwd` -XSOURCE_DIR=`cd ..;pwd` -XSOURCE_DIR2=`cd /localbuild/src/sysnative-prencurses-5.9/Ada95/src;pwd` -XLIB_NAME=AdaCurses -XSONAME=libAdaCurses.so.1 -XLIB_KIND=static gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/build/sysnative-prencurses-5.9/narrowc/Ada95/src/terminal_interface-curses-trace.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-text_io-fixed_io.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-termcap.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-forms-field_types-alpha.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-text_io-integer_io.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-forms-field_types-enumeration-ada.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-text_io-enumeration_io.adb gcc -c -g -O2 -gnatafno -gnatVa -gnatwa -I- -gnatA /localbuild/src/sysnative-prencurses-5.9/Ada95/src/terminal_interface-curses-menus.adb raised STORAGE_ERROR : stack overflow (or erroneous memory access) The following patch to terminal_interface-curses-menus.adb fixes the problem: --- Ada95/src/terminal_interface-curses-menus.adb +++ Ada95/src/terminal_interface-curses-menus.adb @@ -101,7 +101,2 @@ - type Name_String is new char_array (0 .. Name'Length); - type Name_String_Ptr is access Name_String; - pragma Controlled (Name_String_Ptr); - - type Desc_String is new char_array (0 .. Description'Length); - type Desc_String_Ptr is access Desc_String; - pragma Controlled (Desc_String_Ptr); + type String_Ptr is access all char_array; + pragma Controlled (String_Ptr); @@ -109,2 +104,2 @@ - Name_Str : constant Name_String_Ptr := new Name_String; - Desc_Str : constant Desc_String_Ptr := new Desc_String; + Name_Str : constant String_Ptr := new char_array(0 .. Name'Length); + Desc_Str : constant String_Ptr := new char_array(0 .. Description'Length); But this is not a proper solution: original core looks correct to me. ncurses source was pulled from ftp://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz and configured in the following way: /localbuild/src/sysnative-prencurses-5.9/configure --prefix=/sysnative --includedir=/sysnative/include --with-ada-sharedlib --with-shared --disable-termcap --enable-symlinks --with-rcs-ids --enable-const --enable-sp-funcs --enable-colorfgbg --enable-ext-mouse --enable-reentrant --enable-interop --with-pthread --enable-pthreads-eintr --enable-weak-symbols --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu P.S. I'm not an Ada guru - I just wanted to rebuild packages for our local linux flavor using GCC 4.6 and NCurses 5.9...
[Bug middle-end/49731] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49731 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-07-13 13:03:18 UTC --- Fixed by revision 176227: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00493.html
[Bug middle-end/49733] New: Missed optimization: Variable value not propagated to remove if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733
Summary: Missed optimization: Variable value not propagated to
remove if condition
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Based on the discussion at http://gcc.gnu.org/ml/gcc/2011-07/msg00208.html.
In Fortran, the if condition can be removed in the following example as call
some_function() may not modify it. This optimization is done by the Fortran
compilers of NAG, Cray, Sun, Open64 and PathScale. But gfortran (and Intel's
and PGI's compiler) do not optimize the if away, which can be seen from the
presence of the foobar_ function in the dump.
subroutine sub(non_aliasing_var)
interface
subroutine some_function()
end subroutine some_function
end interface
integer :: non_aliasing_var
non_aliasing_var = 5
call some_function()
if (non_aliasing_var /= 5) call foobar_()
end subroutine sub
Optimized dump:
sub (integer(kind=4) restrict non_aliasing_var)
{
integer(kind=4) D.1550;
bb 2:
*non_aliasing_var_1(D) = 5;
some_function ();
D.1550_2 = *non_aliasing_var_1(D);
if (D.1550_2 != 5)
goto bb 3;
else
goto bb 4;
bb 3:
foobar_ (); [tail call]
bb 4:
return;
}
NOTE: Fortran has a case (coarrays, ASYNCHRONOUS), where the current behaviour
is correct: That is, no aliasing of variables in the scoping unit, but the
value might change due to asynchronous I/O / data communication (ASYNCHRONOUS)
- or via one-sided communication (coarrays), where the WAIT or SYNC might be
hidden in some function call. For those cases, the current behaviour with
restrict is correct.
Cf. ASYNCHRONOUS: F2008, Sect. 5.3.4 and PDTR 29113
(ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1866.pdf)
Cf. Coarray: F2008; especially Section 8.5 and, in particular, Subsection
8.5.2.
Regarding the example above, one finds in the Fortran standard (F2008,
ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1866.pdf) the following, which applies
as the dummy argument non_aliasing_var is neither a POINTER nor has it the
TARGET attribute.
While an entity is associated with a dummy argument, the following
restrictions hold.
[...]
(3) Action that affects the value of the entity or any subobject of it shall
be taken only through the dummy argument unless
(a) the dummy argument has the POINTER attribute or
(b) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT(IN), the dummy argument is a scalar object or an assumed-shape
array without the CONTIGUOUS attribute, and the actual argument is a target
other than an array section with a vector subscript.
(4) If the value of the entity or any subobject of it is affected through the
dummy argument, then at any time during the invocation and execution of the
procedure, either before or after the definition, it may be referenced only
through that dummy argument unless
(a) the dummy argument has the POINTER attribute or
(b) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT(IN), the dummy argument is a scalar object or an assumed-shape
array without the CONTIGUOUS attribute, and the actual argument is a target
other than an array section with a
vector subscript.
[Bug fortran/25829] [F2003] Asynchronous IO support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #23 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-13 13:15:39 UTC --- (In reply to comment #22) I think the easiest is to not set the restrict of dummy arguments involved in ASYNCHRONOUS I/O. It seems that GCC understands something different than I by restrict; it seems to be much less aggressive than I thought - and seems to match exactly what we need, such that no action seems to be required. Cf. http://gcc.gnu.org/ml/gcc/2011-07/msg00208.html and see PR 49733 for a missed-optimization PR, which is for adding an variable attribute which does optimize across function calls - which is allowed most of the time in Fortran (except for ASYNCHRONOUS and for coarrays).
[Bug c++/49734] New: Adding using std::for_each inconsistent with return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49734
Summary: Adding using std::for_each inconsistent with return
value
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marat.buha...@gmail.com
Look at that code (summing on c using indices in l):
---
#include iostream
#include algorithm
struct Adder {
int acc;
int *cv;
void operator()(int x) { acc += cv[x]; std::cout acc std::endl; }
};
int main()
{
int c[] = {1, 1, 1, 1, 1};
int l[] = {0, 1, 2, 3, 4};
Adder add = {0, c};
std::for_each(l, l + 5, add);
std::cout add.acc std::endl;
}
---
in void Adder::operator()(int) acc puts in stdout. And I can see as the value
in accumulator(acc) increments over iterationы in std::for_each.
But in the last line of int main() it turns out that add.acc contains 0
(Expected value is 5)
[Bug middle-end/49733] Missed optimization: Variable value not propagated to remove if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-13
13:42:26 UTC ---
C test case matching the Fortran one, which also shows that the if is not
optimized away.
void some_function(void);
void
sub (int *restrict non_aliasing_var)
{
*non_aliasing_var = 5;
some_function ();
if (*non_aliasing_var != 5)
foobar_();
}
[Bug c++/49734] Adding using std::for_each inconsistent with return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49734 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-13 13:51:00 UTC --- This is conforming behavior, because std::for_each takes its third argument *by value*.
[Bug middle-end/49733] Missed optimization: Variable value not propagated to remove if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-13 14:06:17 UTC --- (In reply to comment #1) C test case matching the Fortran one, which also shows that the if is not optimized away. According to Ian (cf. thread linked to in comment 0), C99's restrict does not guarantee that the value remains the same after a function call. Assuming that's the case, then C does not seem to have an equivalent qualifier to Fortran's nontarget/nonasynchronous/nonpointer* variables. - And, hence, some tree flag is missing to for such nonpointer* Fortran variables. (* pointer in the Fortran sense.) I failed to see this from C99's 6.7.3.1 Formal definition of restrict, which is written in a rather convoluted way.
[Bug middle-end/49733] Missed optimization: Variable value not propagated to remove if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-13 14:17:38 UTC --- is program test integer :: a subroutine bar() a = 1 end subroutine sub(non_aliasing_var) integer :: non_aliasing_var non_aliasing_var = 5 bar() if (non_aliasing_var /= 5) call foobar() end sub(a) end invalid then? GCC assumes that any function can modify any global variable unless interprocedural analysis can prove otherwise. It gets more interesting when you consider subroutine sub(non_aliasing_var) integer :: non_aliasing_var non_aliasing_var = 5 sub(a) ! or even ! sub (non_aliasing_var) if (non_aliasing_var /= 5) call foobar() end (or even hide the recursion by going through an external dispatcher) Does that make the variable aliased? Or is that invalid as well (ok, add whatever is required to allow sub be called recursively - what then?)
[Bug tree-optimization/49735] New: mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 Summary: mips64-elf libgcc build fails with apparently infinite recursion. Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ber...@gcc.gnu.org Created attachment 24751 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24751 A testcase Configure a cross compiler with --target=mips64-elf. When building libgcc, cc1 goes into what seems to be an infinite recursion: (gdb) bt #0 0x083b22aa in estimate_calls_size_and_time (node=value optimized out, size=0xf7484030, time=0xf748402c, possible_truths=4294967294) at ../../trunk/gcc/ipa-inline-analysis.c:1748 #1 0x083b229d in estimate_calls_size_and_time (node=value optimized out, size=0xf7484030, time=0xf748402c, possible_truths=4294967294) at ../../trunk/gcc/ipa-inline-analysis.c:1743 #2 0x083b229d in estimate_calls_size_and_time (node=value optimized out, size=0xf7484030, time=0xf748402c, possible_truths=4294967294) at ../../trunk/gcc/ipa-inline-analysis.c:1743 I'm attaching the .i file.
[Bug c++/49734] Adding using std::for_each inconsistent with return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49734 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-13 14:29:35 UTC --- You probably want to use the return value: add = std::for_each(l, l + 5, add); Although for this specific case you could #include numeric and use std::accumulate int acc = std::accumulate(c, c + 5, 0);
[Bug middle-end/49733] Missed optimization: Variable value not propagated to remove if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-13 14:42:43 UTC --- (In reply to comment #3) is [...] invalid then? Yes, the does not even have the correct syntax. I assume you means something like: module m integer :: global end module m program main use m implicit none call test(global) contains subroutine mod_global() global = 7 end subroutine mod_global subroutine mod2(y) integer :: y y = 9 end subroutine mod2 subroutine test(x) integer :: x x = 5 call mod_global() ! Invalid, modifies x global = 8 ! Also invalid call mod2(global) ! Ditto. print *, x ! May print 5, 7, 8, 9, or other garbage end subroutine end program main ! or even ! sub (non_aliasing_var) if (non_aliasing_var /= 5) call foobar() Well, call sub (non_aliasing_var) *may* modify non_aliasing_var - but it may not modify a global variable directly, if it is associated with the actual argument. (And for recursion: That's only allowed if the procedure is marked as RECURSIVE.) As written, the Fortran standard states (quote in comment 0): If A is used as actual argument to the dummy argument D then: a) Anything which *modifies* A should only be done by using explicitly D, unless D is a POINTER or D has the TARGET attribute (and some other conditions). b) Anything which *reads* A: If the value is modified through D, only D may be used to access the value. (With same exceptions for TARGET and POINTER - and, of course, only applying until the function with the dummy D returns).
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #5 from razya at gcc dot gnu.org 2011-07-13 15:06:50 UTC ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
Why is
D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number
of loop
iterations. */
of type __int128? That looks bogus.
the size of 128 was determined according to the precision of the ivs in
canonicalize_loop_ivs:
canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
{
unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
gimple phi = gsi_stmt (psi);
tree res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res))
precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1); // precision ==
128
...
}
Does it seem that the precision should not determine the new type size,
or that
the precision itself being 128 is strange?
Well, autopar seems to introduce this 128 bit type in the first place,
and I wonder why it does that. And it definitely should avoid doing this.
What happens is that autopar calls canonicalize_loop_ivs() when it is starting
to change the loop.
Here's a part of the documentation of canonicalize_loop_ivs():
When the IV type precision has to be larger
than *NIT type precision, *NIT is converted to the larger type, the
conversion code is inserted before the loop, and *NIT is updated to
the new definition.
In this case of cactusADM, one of the loop's IVs indeed has a precision of
128,
and therefore a conversion to a type of 128 bit is created.
I checked the precision of the loop's IVs a few passes before autopar, and
even
when I disable autopar, and indeed there is an IV that has a type with 128
precision.
I tried to build cactusADM on linux-x86 with autopar enabled, and I get
segmentation fault due to the same reason.
It happens when either -m32c or -m64 is enabled.
/Develop/razya/gcc-cactus/bin/gcc -c -o PUGHReduce/ReductionNormInf.o
-DSPEC_CPU -DNDEBUG -Iinclude -I../include -DCCODE -O2
-ftree-parallelize-loops=4 -ffast-math -DSPEC_CPU_LP64
PUGHReduce/ReductionNormInf.c
PUGHReduce/ReductionNormInf.c: In function 'PUGH_ReductionNormInf':
PUGHReduce/ReductionNormInf.c:207:12: 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.
specmake: *** [PUGHReduce/ReductionNormInf.o] Error 1
The type is NULL at line 1218 in canonicalize_loop_ivs:
1214 type = lang_hooks.types.type_for_size (precision, 1);
1215
1216 if (original_precision != precision)
1217{
1218 *nit = fold_convert (type, *nit);
1219 *nit = force_gimple_operand (*nit, stmts, true, NULL_TREE);
1220 if (stmts)
1221gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop),
stmts);
1222}
The size according to which the type is supposed to be created (line 1214) is
80.
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471 razya at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.13 15:12:12 AssignedTo|unassigned at gcc dot |razya at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #22 from joerg.rich...@pdv-fs.de 2011-07-13 15:11:21 UTC ---
Is it possible to fix it for 4.6.2?
Following program is a 4.4 regression (when using -std=gnu++0x):
---8-
#include cassert
#include vector
#include algorithm
using namespace std;
int main( int, char** )
{
vectorint v;
v.push_back( 1 );
stable_sort( v, v+1 );
assert( v.size() == 1 );
return 0;
}
---8-
Works with 4.4.1, fails with 4.5 and 4.6
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-13 15:20:23 UTC --- To be honest, isn't a real regression, because you are using -std=gnu++0x, and simply in 4.4.x we had no C++0x conforming std::stable_sort. In general, my feeling is that the fix is too invasive for 4.6.x, but please stress it as much as possible and if in a couple of weeks no regressions will appear we can reconsider a backport.
[Bug c++/49734] Adding using std::for_each inconsistent with return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49734
--- Comment #3 from MaratIK marat.buharov at gmail dot com 2011-07-13
15:23:52 UTC ---
(In reply to comment #2)
int acc = std::accumulate(c, c + 5, 0);
Thanks. I used overloaded std::accumulate with BinaryOperation (Adder) because
indices for c are in l.
---
struct Adder {
int *cv;
Adder(int *c) : cv(c) {}
int operator()(int x, int y) { return x + cv[y]; }
};
---
int acc = std::accumulate(l, l + 5, 0, Adder(c));
---
With lambda it will be simpler
[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |target --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2011-07-13 15:24:34 UTC --- Looks like a target bug in pa.md.
[Bug ada/49725] [4.6 Regression] FAIL: c34005a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49725 --- Comment #2 from dave.anglin at bell dot net 2011-07-13 16:00:24 UTC --- On 7/13/2011 4:26 AM, rguenth at gcc dot gnu.org wrote: Does it work on trunk then? Yes. The only change that I see that could cause this is: 2011-07-11 Martin Jambor mjam...@suse.cz PR tree-optimization/49094 * tree-sra.c (tree_non_mode_aligned_mem_p): New function. (build_accesses_from_assign): Use it. Dave
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 16:11:25 UTC --- Since I could only run the bootstrap on a Solaris 8 branded zone where the default libthread.so is a copy of the lwp one, could you try it on bare metal to confirm that it works? Works essentially OK by me. The only remaining glitches are: === libgomp Summary for unix/ === # of expected passes2572 # of unsupported tests 10 Running target unix//-m64 FAIL: libgomp.fortran/condinc2.f -O (test for excess errors) WARNING: libgomp.fortran/condinc2.f -O compilation failed to produce executabl e FAIL: libgomp.fortran/condinc4.f90 -O (test for excess errors) WARNING: libgomp.fortran/condinc4.f90 -O compilation failed to produce executa ble FAIL: libgomp.fortran/omp_cond2.f -O (test for excess errors) WARNING: libgomp.fortran/omp_cond2.f -O compilation failed to produce executab le FAIL: libgomp.fortran/omp_cond4.F90 -O (test for excess errors) WARNING: libgomp.fortran/omp_cond4.F90 -O compilation failed to produce execut able output is: Undefined first referenced symbol in file __tls_get_addr /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/sparc-sun-solaris2.8/sparcv9/libgomp/.libs/libgomp.so ld: fatal: Symbol referencing errors. No output written to ./condinc2.exe collect2: error: ld returned 1 exit status FAIL: libgomp.fortran/condinc2.f -O (test for excess errors but this is more of a test harness issue: the 4 tests are compiled with the combination -fno-openmp -lgomp so -pthread isn't added by the driver.
[Bug ada/48711] [4.6/4.7 regression] failure to bootstrap or build ada for mingw (value not in range of type Interfaces.C.unsigned in g-socthi.adb)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48711 --- Comment #1 from Rainer Emrich rai...@emrich-ebersheim.de 2011-07-13 16:16:09 UTC --- It's the same for a native i686-pc-mingw32 bootstrap using msys. See also PR 49625 and 48151, which are duplicates. A patch is proposed here http://gcc.gnu.org/ml/gcc/2010-09/msg00228.html
[Bug ada/48711] [4.6/4.7 regression] failure to bootstrap or build ada for mingw (value not in range of type Interfaces.C.unsigned in g-socthi.adb)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48711 --- Comment #2 from Rainer Emrich rai...@emrich-ebersheim.de 2011-07-13 16:22:14 UTC --- (In reply to comment #1) It's the same for a native i686-pc-mingw32 bootstrap using msys. See also PR 49625 and 48151, which are duplicates. A patch is proposed here http://gcc.gnu.org/ml/gcc/2010-09/msg00228.html Only Windows versions XP and older are affected and the proposed patch solves the issue.
[Bug middle-end/49736] New: [4.7 Regression] Revision 176228 miscompiled 255.vortex in SPEC CPU 2000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49736 Summary: [4.7 Regression] Revision 176228 miscompiled 255.vortex in SPEC CPU 2000 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: rsand...@gcc.gnu.org On Linux/x86-64, revision 176228: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00494.html miscompiled 255.vortex in SPEC CPU 2000: gcc -O2 -ffast-math -DSPEC_CPU2000_LP64 bitvec.o bmt.o bmt0.o bmt01.o bmt10.o bmtlib.o bmtobj.o core01.o dba.o dbm0.o dbm1.o dbm2.o domain.o draw07.o draw7.o drawlib.o drawobj.o emplib.o empobj.o env0.o env01.o env1.o fm.o gdbm.o grp0.o grp1.o grp2.o hm.o iam.o ifm.o im.o km.o list01.o mem00.o mem01.o mem10.o oa0.o oa1.o oadmp.o obj01.o odbm.o ogrp.o om.o point.o primal.o pstub.o query.o rect.o rects.o sa.o shell.o sm.o testobj.o tm.o trans00.o trans01.o trans10.o trans20.o tree0.o tree00.o tree01.o ut.o vchunk.o vdbm.o voa.o vom.o -lm -o vortex Running 255.vortex ref base lnx32e-gcc default *** Miscompare of vortex3.out, see /export/regression/rrs/spec/2000/spec/benchsp ec/CINT2000/255.vortex/run/0002/vortex3.out.mis *** Miscompare of vortex1.out, see /export/regression/rrs/spec/2000/spec/benchsp ec/CINT2000/255.vortex/run/0002/vortex1.out.mis *** Miscompare of vortex2.out, see /export/regression/rrs/spec/2000/spec/benchsp ec/CINT2000/255.vortex/run/0002/vortex2.out.mis
[Bug bootstrap/49737] New: [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 Summary: [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: r...@cebitec.uni-bielefeld.de Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Bootstrap fail on x86_64-apple-darwin10 at revision 176240 with: ... /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../.././gcc -I../../../work/libgcc -I../../../work/libgcc/. -I../../../work/libgcc/../gcc -I../../../work/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _gcov_execve.o -MT _gcov_execve.o -MD -MP -MF _gcov_execve.dep -DL_gcov_execve -c ../../../work/libgcc/libgcov.c /usr/bin/ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols ranlib libgcc_eh.a ranlib: file: libgcc_eh.a(unwind-sjlj.o) has no symbols # If the gcc directory specifies which extra parts to # build for this target, and the libgcc configuration also # specifies, make sure they match. This can be removed # when the gcc directory no longer holds libgcc configuration; # it is useful when migrating a target. Configuration mismatch! Extra parts from gcc directory: crtfastmath.o crtprec32.o crtprec64.o crtprec80.o Extra parts from libgcc: crt3.o exit 1 make[5]: *** [libgcc-extra-parts] Error 1 ...
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-13 17:00:22 UTC --- # If the gcc directory specifies which extra parts to # build for this target, and the libgcc configuration also # specifies, make sure they match. This can be removed # when the gcc directory no longer holds libgcc configuration; # it is useful when migrating a target. Configuration mismatch! Extra parts from gcc directory: crtfastmath.o crtprec32.o crtprec64.o crtprec80.o Extra parts from libgcc: crt3.o exit 1 make[5]: *** [libgcc-extra-parts] Error 1 ... This just occured to me when I was about to commit the i386/crtprec patch. Testing for that one has completed successfully, but even if I commit that one, the crtfastmath one is still pending. I've just submitted the revised version, asking for approval so I can commit both i386/crtprec and crtfastmath to gether to get us out of this mess. Sorry. Rainer
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-13 17:03:30 UTC --- I configured the build with ../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto A nonparallel make gives # If this is the top-level multilib, build all the other # multilibs. /bin/sh ../../../../work/libgcc/../mkinstalldirs ../../.././gcc/i386 for file in libgcc_s.1.dylib libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib; do \ rm -f ../../.././gcc/i386/$file;\ ln -s ../$file ../../.././gcc/i386/;\ done rm -f ../../.././gcc/i386/libgcc_s_x86_64.1.dylib ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_x86_64.1.dylib rm -f ../../.././gcc/i386/libgcc_s_ppc64.1.dylib-- ppc64 seems quite suspicious here ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_ppc64.1.dylib # If the gcc directory specifies which extra parts to # build for this target, and the libgcc configuration also # specifies, make sure they match. This can be removed # when the gcc directory no longer holds libgcc configuration; # it is useful when migrating a target. Configuration mismatch! Extra parts from gcc directory: crtfastmath.o crtprec32.o crtprec64.o crtprec80.o Extra parts from libgcc: crt3.o
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-13 17:10:14 UTC --- rm -f ../../.././gcc/i386/libgcc_s_x86_64.1.dylib ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_x86_64.1.dylib rm -f ../../.././gcc/i386/libgcc_s_ppc64.1.dylib-- ppc64 seems quite suspicious here ln -s libgcc_s.1.dylib \ ../../.././gcc/i386/libgcc_s_ppc64.1.dylib This has nothing to do with the problem at hand. It's from libgcc/config/t-slibgcc-darwin (install-darwin-libgcc-stubs) where the symlinks are created unconditionally, irrespective of target. Rainer
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-13 17:28:11 UTC --- With the patch in http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01068.html, bootstrap fails with: make[5]: *** No rule to make target `../../../../work/libgcc/config/i386/crtfastmath.c', needed by `crtfastmath.o'. Stop. at stage1 for -m32.
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-13 17:39:51 UTC --- With the patch in http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01068.html, bootstrap fails with: Apparently something went wrong in the patching process, trying revision 176241.
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-13 17:43:32 UTC --- --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-13 17:39:51 UTC --- With the patch in http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01068.html, bootstrap fails with: Apparently something went wrong in the patching process, trying revision 176241. You could probably say so: those are git-style patches containing renames, and only git GNU patch can handle those, otherwise you have to perform them manually. That said, please update to rev 176242 instead. Unless I made a mistake, that one should bootstrap again. Sorry for the mess. Rainer
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-13 17:56:26 UTC --- --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 16:11:25 UTC --- Since I could only run the bootstrap on a Solaris 8 branded zone where the default libthread.so is a copy of the lwp one, could you try it on bare metal to confirm that it works? Works essentially OK by me. The only remaining glitches are: Fine, I'll commit the patch then. output is: Undefined first referenced symbol in file __tls_get_addr /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/sparc-sun-solaris2.8/sparcv9/libgomp/.libs/libgomp.so ld: fatal: Symbol referencing errors. No output written to ./condinc2.exe collect2: error: ld returned 1 exit status FAIL: libgomp.fortran/condinc2.f -O (test for excess errors but this is more of a test harness issue: the 4 tests are compiled with the combination -fno-openmp -lgomp so -pthread isn't added by the driver. This is strange: in my case, libgomp.so is self-contained and linked with the right libthread.so which provides __tls_get_addr: LD_LIBRARY_PATH=. ldd -r ./libgomp.so.1 librt.so.1 =/usr/lib/64/librt.so.1 libgcc_s.so.1 = ./libgcc_s.so.1 libpthread.so.1 = /usr/lib/64/libpthread.so.1 libthread.so.1 =/usr/lib/lwp/64/libthread.so.1 libc.so.1 = /usr/lib/64/libc.so.1 libaio.so.1 = /usr/lib/64/libaio.so.1 libdl.so.1 =/usr/lib/64/libdl.so.1 /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1 Rainer
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2011-07-13 17:58:20 UTC --- Author: ro Date: Wed Jul 13 17:58:18 2011 New Revision: 176244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176244 Log: PR target/49541 * config/sol2.h (LIB_SPEC): Simplify. Move LIB_THREAD_LDFLAGS_SPEC ... (LINK_SPEC): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sol2.h
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-13 18:11:57 UTC --- That said, please update to rev 176242 instead. Unless I made a mistake, that one should bootstrap again. I am now at stage 2.
[Bug bootstrap/49737] [4.7 Regression] Bootstrap failure at revision 176240 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49737 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-13 18:20:48 UTC --- I am now at stage 2. Great. Please close the PR one bootstrap finished. Thanks. Rainer
[Bug fortran/49738] New: Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738 Summary: Compile errors on OSX darwin 11 (Lion) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bosephu...@gmail.com checking dynamic linker characteristics... darwin11 dyld checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc44/work/build/x86_64-apple-darwin11/libgfortran/config.log
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 --- Comment #16 from Janne Blomqvist jb at gcc dot gnu.org 2011-07-13 18:46:48 UTC --- Author: jb Date: Wed Jul 13 18:46:44 2011 New Revision: 176245 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176245 Log: PR 49296 List read, EOF without preceding separator 2011-07-13 Janne Blomqvist j...@gcc.gnu.org PR libfortran/49296 * io/list_read.c (read_logical): Don't error out if a valid value is followed by EOF instead of a normal separator. (read_integer): Likewise. testsuite: 2011-07-13 Janne Blomqvist j...@gcc.gnu.org PR libfortran/49296 * gfortran.dg/read_list_eof_1.f90: Add tests for integer, real, and logical reads. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/read_list_eof_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug bootstrap/49739] New: [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49739 Summary: [4.7 Regression] bootstrap failure Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 176244 gave # If the gcc directory specifies which extra parts to # build for this target, and the libgcc configuration also # specifies, make sure they match. This can be removed # when the gcc directory no longer holds libgcc configuration; # it is useful when migrating a target. Configuration mismatch! Extra parts from gcc directory: crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o Extra parts from libgcc: crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o crtprec64.o crtprec80.o crtfastmath.o exit 1 make[6]: *** [libgcc-extra-parts] Error 1 Revision 176240 is OK.
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 --- Comment #17 from Janne Blomqvist jb at gcc dot gnu.org 2011-07-13 18:52:43 UTC --- Author: jb Date: Wed Jul 13 18:52:40 2011 New Revision: 176246 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176246 Log: PR 49296 List read, EOF before separator, backport from trunk 2011-07-13 Janne Blomqvist j...@gcc.gnu.org PR libfortran/49296 * io/list_read.c (read_logical): Don't error out if a valid value is followed by EOF instead of a normal separator. (read_integer): Likewise. testsuite: 2011-07-13 Janne Blomqvist j...@gcc.gnu.org PR libfortran/49296 * gfortran.dg/read_list_eof_1.f90: Add tests for integer, real, and logical reads. Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/read_list_eof_1.f90 branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/io/list_read.c
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Janne Blomqvist jb at gcc dot gnu.org 2011-07-13 18:54:09 UTC --- Fixed on trunk (4.7) and 4.6, closing.
[Bug bootstrap/49739] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49739 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-07-13 19:00:54 UTC --- Created attachment 24752 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24752 proposed patch Drats, I've missed that part of the i[34567]86-*-linux* case. Could you please try the attached patch. It's just a hack, but probably will have to do for now. I'm working to move the other files in EXTRA_PARTS and EXTRA_MULTILIB_PARTS over so this split/duplicate configuration cannot occur any longer.
[Bug fortran/49738] Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.07.13 19:10:58 CC||kargl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org 2011-07-13 19:10:58 UTC --- This normally means that you are missing one or more of the required libraries: GMP, MPFR, or MPC. Please check that these are installed and gcc can find the libs.
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-13 19:34:48 UTC --- This is strange: in my case, libgomp.so is self-contained and linked with the right libthread.so which provides __tls_get_addr: LD_LIBRARY_PATH=. ldd -r ./libgomp.so.1 librt.so.1 =/usr/lib/64/librt.so.1 libgcc_s.so.1 = ./libgcc_s.so.1 libpthread.so.1 = /usr/lib/64/libpthread.so.1 libthread.so.1 =/usr/lib/lwp/64/libthread.so.1 libc.so.1 = /usr/lib/64/libc.so.1 libaio.so.1 = /usr/lib/64/libaio.so.1 libdl.so.1 =/usr/lib/64/libdl.so.1 /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1 Same here, but the link line starts with: /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/gcc/collect2 -V -Y P,/lib/sparcv9:/usr/lib/sparcv9 -Qy -o ./condinc2.exe and this apparently overrides it.
[Bug bootstrap/49740] New: [4.7 Regression] powerpc native bootstrap with -O3 produces Bootstrap comparison failure!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740 Summary: [4.7 Regression] powerpc native bootstrap with -O3 produces Bootstrap comparison failure! Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: dougmenc...@gmail.com Bootstrap comparison failure! After http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 (well-hidden wrong comparison in rtl (cprop.c)) has been fixed, I succeeded to stage3, and got: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/fold-const.o differs gcc/tree-into-ssa.o differs gcc/cfgrtl.o differs gcc/gimplify.o differs gcc/build/genattrtab.o differs ... Full bootstrap log is available at: http://ftp.osuosl.org/pub/manulix/logs+errors/gcc-v4.7-20110709-bootstrap.log
[Bug other/49533] [4.7 regression] Revision 174989 (ipa-inline-transform.c) regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533
--- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-07-13 21:13:31 UTC ---
Hmm, that whole approach doesn't seem to work.
The following patch survives building of stellarium and explains the
failures that I've reported above:
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index c329bea..bef1d38 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -122,7 +122,10 @@ can_remove_node_now_p (struct cgraph_node *node, struct
cgraph_edge *e)
next != node; next = next-same_comdat_group)
if (node-callers node-callers != e
!can_remove_node_now_p_1 (node))
- return false;
+ {
+gcc_unreachable();
+return false;
+ }
return true;
}
Even when one changes node to next in the if clause,
next-callers == e is always true and the following
patch also survives building of stellarium. But it merely
brings us back to the status quo before commit 7791b0eb56c3c
went in...
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index c329bea..2a09de8 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -120,9 +120,13 @@ can_remove_node_now_p (struct cgraph_node *node, struct
cgraph_edge *e)
return true;
for (next = node-same_comdat_group;
next != node; next = next-same_comdat_group)
-if (node-callers node-callers != e
-!can_remove_node_now_p_1 (node))
- return false;
+if (next-callers
+!can_remove_node_now_p_1 (next))
+ {
+gcc_assert (next-callers == e);
+return false;
+ }
+ gcc_unreachable();
return true;
}
[Bug fortran/49738] Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-13
21:45:23 UTC ---
If you built stock gmp 5.0.2 under llvm-gcc, you have a broken gmp (which a
make check will show you). The fix is to apply...
-- gmp-5.0.2/acinclude.m4.orig 2011-05-17 19:03:09.0 -0400
+++ gmp-5.0.2/acinclude.m4 2011-05-17 19:03:43.0 -0400
@@ -1941,8 +1941,8 @@
esac
cat conftest.c EOF
-extern const int foo[];/* Suppresses C++'s suppression of foo
*/
-const int foo[] = {1,2,3};
+extern const int foo[[]]; /* Suppresses C++'s suppression of foo
*/
+const int foo[[]] = {1,2,3};
EOF
echo Test program: AC_FD_CC
cat conftest.c AC_FD_CC
--- gmp-5.0.2/configure.orig2011-05-17 19:15:41.0 -0400
+++ gmp-5.0.2/configure 2011-05-17 19:16:00.0 -0400
@@ -26446,8 +26446,8 @@
esac
cat conftest.c EOF
-extern const int foo; /* Suppresses C++'s suppression of foo */
-const int foo = {1,2,3};
+extern const int foo[];/* Suppresses C++'s suppression of foo */
+const int foo[] = {1,2,3};
EOF
echo Test program: 5
cat conftest.c 5
http://gmplib.org/list-archives/gmp-bugs/2011-April/002236.html
http://gmplib.org/list-archives/gmp-bugs/2011-May/002255.html
http://gmplib.org/list-archives/gmp-bugs/2011-May/002256.html
[Bug fortran/49738] Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738
--- Comment #3 from bosephus61 at gmail dot com 2011-07-13 21:53:19 UTC ---
I'll have to check as that's likely the case since I have apple Xcode 4.1
installed.
On Jul 13, 2011, at 2:46 PM, howarth at nitro dot med.uc.edu wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-13
21:45:23 UTC ---
If you built stock gmp 5.0.2 under llvm-gcc, you have a broken gmp (which a
make check will show you). The fix is to apply...
-- gmp-5.0.2/acinclude.m4.orig 2011-05-17 19:03:09.0 -0400
+++ gmp-5.0.2/acinclude.m4 2011-05-17 19:03:43.0 -0400
@@ -1941,8 +1941,8 @@
esac
cat conftest.c EOF
-extern const int foo[];/* Suppresses C++'s suppression of foo
*/
-const int foo[] = {1,2,3};
+extern const int foo[[]]; /* Suppresses C++'s suppression of foo
*/
+const int foo[[]] = {1,2,3};
EOF
echo Test program: AC_FD_CC
cat conftest.c AC_FD_CC
--- gmp-5.0.2/configure.orig2011-05-17 19:15:41.0 -0400
+++ gmp-5.0.2/configure 2011-05-17 19:16:00.0 -0400
@@ -26446,8 +26446,8 @@
esac
cat conftest.c EOF
-extern const int foo; /* Suppresses C++'s suppression of foo */
-const int foo = {1,2,3};
+extern const int foo[];/* Suppresses C++'s suppression of foo */
+const int foo[] = {1,2,3};
EOF
echo Test program: 5
cat conftest.c 5
http://gmplib.org/list-archives/gmp-bugs/2011-April/002236.html
http://gmplib.org/list-archives/gmp-bugs/2011-May/002255.html
http://gmplib.org/list-archives/gmp-bugs/2011-May/002256.html
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug target/49656] internal compiler error on Mac OS 10.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49656 --- Comment #3 from andreas at galauner dot de 2011-07-13 22:09:11 UTC --- I just compiled GCC 4.6.1 again without clang after I found out how to do that. By defining CC = /usr/bin/gcc-4.2 CPP = /usr/bin/cpp-4.2 CXX = /usr/bin/g++-4.2 LD = /usr/bin/gcc-4.2 before the configure step the Apple GCC is used for compilation. If you don't do that, clang will be used on Mac OS with XCode 4 and this leads to this internal compiler error. So, it doesn't seem to be a GCC issue.
[Bug fortran/49738] Compile errors on OSX darwin 11 (Lion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49738 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-13 22:21:38 UTC --- Also note that... 2011-06-19 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * configure.ac: Use mh-x86-darwin. * configure: Regenerate. config: 2011-06-19 Jack Howarth howa...@bromo.med.uc.edu PR target/49461 * mh-x86-darwin: Add file and pass -no_pie on BOOT_LDFLAGS for darwin11. Modified: branches/gcc-4_5-branch/ChangeLog branches/gcc-4_5-branch/config/ChangeLog ...hasn't been backported to gcc-4_4-branch. Without this change, pch in FSF gcc is broken on darwin11 as well as gcj/ecj1.
[Bug bootstrap/49740] [4.7 Regression] powerpc native bootstrap with -O3 produces Bootstrap comparison failure!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740 Douglas Mencken dougmencken at gmail dot com changed: What|Removed |Added Severity|minor |normal
[Bug driver/49726] -g0 file.S -g does not produce debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-13 23:05:31 UTC --- Why .c and .S behave differently wrt -g application rules? Because something goes wrong in either the driver or as (which GCC has no control over).
[Bug driver/49726] -g0 file.S -g does not produce debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-13
23:08:31 UTC ---
The problem is that the specs don't understand that -g0 is overridden by -g in
the driver. In the cc1/cc1plus/fortran1 case, the driver passes -g* directly
to those programs but in the as case, it has to do something special:
#ifndef ASM_DEBUG_SPEC
# if defined(DBX_DEBUGGING_INFO) defined(DWARF2_DEBUGGING_INFO) \
defined(HAVE_AS_GDWARF2_DEBUG_FLAG)
defined(HAVE_AS_GSTABS_DEBUG_FLAG)
# define ASM_DEBUG_SPEC\
(PREFERRED_DEBUGGING_TYPE == DBX_DEBUG\
? %{!g0:%{gdwarf-2*:--gdwarf2}%{!gdwarf-2*:%{g*:--gstabs}}} ASM_MAP
\
: %{!g0:%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}} ASM_MAP)
# else
# if defined(DBX_DEBUGGING_INFO) defined(HAVE_AS_GSTABS_DEBUG_FLAG)
# define ASM_DEBUG_SPEC %{g*:%{!g0:--gstabs}} ASM_MAP
# endif
# if defined(DWARF2_DEBUGGING_INFO) defined(HAVE_AS_GDWARF2_DEBUG_FLAG)
# define ASM_DEBUG_SPEC %{g*:%{!g0:--gdwarf2}} ASM_MAP
# endif
# endif
#endif
#ifndef ASM_DEBUG_SPEC
# define ASM_DEBUG_SPEC
#endif
[Bug driver/49726] -g0 file.S -g does not produce debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.13 23:09:04 Ever Confirmed|0 |1
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build, ice-on-valid-code Target||mips64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.13 23:12:32 Target Milestone|--- |4.7.0 Summary|mips64-elf libgcc build |[4.7 Regression] mips64-elf |fails with apparently |libgcc build fails with |infinite recursion. |apparently infinite ||recursion. Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-13 23:12:32 UTC --- Confirmed.
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-13
23:18:11 UTC ---
Here is a short testcase:
typedef unsigned int UQItype __attribute__((mode (QI)));
static
UQItype sync_fetch_and_add_1 (UQItype *ptr, UQItype value)
{
return __sync_fetch_and_add (ptr, value);
};
typeof (sync_fetch_and_add_1) __sync_fetch_and_add_1 __attribute__((alias
(sync_fetch_and_add _ 1)));
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-13 23:21:26 UTC --- I almost want to say it was caused by: r175169 | hubicka | 2011-06-18 01:33:47 -0700 (Sat, 18 Jun 2011) | 31 lines
[Bug tree-optimization/49735] [4.7 Regression] mips64-elf libgcc build fails with apparently infinite recursion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49735 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-14 00:07:51 UTC --- This patch fixes the infinite loop: Index: ipa-inline.c === --- ipa-inline.c(revision 176253) +++ ipa-inline.c(working copy) @@ -1170,6 +1170,10 @@ recursive_inlining (struct cgraph_edge * /* Make sure that function is small enough to be considered for inlining. */ if (estimate_size_after_inlining (node, edge) = limit) return false; + /* Inlining a builtin recursively into itself should not be done. */ + if (DECL_BUILT_IN (edge-callee-decl)) +return false; + heap = fibheap_new (); lookup_recursive_calls (node, node, heap); if (fibheap_empty (heap)) --- CUT ---
[Bug testsuite/49741] New: make -k check-c++0x not multilib aware
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49741
Summary: make -k check-c++0x not multilib aware
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
On x86_64-apple-darwin11, gcc trunk at r176255 built with...
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.0.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.7-20110713/configure --prefix=/sw
--prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl
--enable-build-with-cxx
Thread model: posix
gcc version 4.7.0 20110713 (experimental) (GCC)
fails many tests at -m32 when using...
make -k check-c++0x RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
in the gcc build directory. These failures seem to be of the form...
Executing on host:
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite.c++0x/g++/../../g++
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite.c++0x/g++/../../
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110713/gcc/testsuite/g++.dg/bprob/g++-bprob-1.C
-nostdinc++
-I/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/libstdc++-v3/include/x86_64-apple-darwin11.0.0
-I/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110713/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110713/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110713/libstdc++-v3/testsuite/util
-std=gnu++0x -fmessage-length=0 -g -fprofile-arcs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/./libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/./libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/./libstdc++-v3/src/.libs
-multiply_defined suppress -lm -m32 -o
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite.c++0x/g++/g++-bprob-1.x01
(timeout = 300)
ld: warning: ignoring file
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/./libstdc++-v3/src/.libs/libstdc++.dylib,
file was built for unsupported file format which is not the architecture being
linked (i386)^M
output is:
ld: warning: ignoring file
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin11.0.0/./libstdc++-v3/src/.libs/libstdc++.dylib,
file was built for unsupported file format which is not the architecture being
linked (i386)^M
FAIL: g++.dg/bprob/g++-bprob-1.C compilation, -g -fprofile-arcs
UNRESOLVED: g++.dg/bprob/g++-bprob-1.C execution,-g -fprofile-arcs
suggesting that the testing harness is mixing -m32 and -m64 code when testing
-m32.
[Bug tree-optimization/49742] New: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742
Summary: ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
Test gcc.dg/vect/O3/pr39675-2.c fails with an ICE on arm-none-linux-gnueabi:
Executing on host: arm-none-linux-gnueabi-gcc
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c
-mfpu=neon -mfloat-abi=softfp -ffast-math -ftree-vectorize
-fno-vect-cost-model -O2 -fdump-tree-vect-details -O3 -fno-ipa-cp-clone -S -o
O3-pr39675-2.s(timeout = 300)
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:
In function 'foo':
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
error: insn does not satisfy its constraints:
(insn 95 37 44 2 (set (reg:V2SI 95 d16 [orig:177 vect_array.21_I_lsm0.31 ]
[177])
(mem/u/c/i:V2SI (symbol_ref/u:SI (*.LC0) [flags 0x2]) [3 S8 A64]))
750 {*neon_movv2si}
(nil))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/vect/O3-pr39675-2.c:27:1:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The same failure results if the test program is compiled with options
-mfpu=neon -mfloat-abi=softfp -O3.
The test starts failing with this patch:
2011-06-30 Richard Guenther rguent...@suse.de
PR tree-optimization/46787
* tree-data-ref.c (dr_address_invariant_p): Remove.
(find_data_references_in_stmt): Invariant accesses are ok now.
* tree-vect-stmts.c (vectorizable_load): Handle invariant
loads.
* tree-vect-data-refs.c (vect_analyze_data_ref_access): Allow
invariant loads.
* gcc.dg/vect/vect-121.c: New testcase.
r175704 | rguenth | 2011-06-30 13:27:43 + (Thu, 30 Jun 2011)
[Bug c/49743] New: -g enables var_tracking on -O0 - causes long compilations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49743 Summary: -g enables var_tracking on -O0 - causes long compilations Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ne...@intrepid.com CC: j...@suse.cz, g...@intrepid.com, phhargr...@lbl.gov Host: x86_64-apple-darwin10.8.0 Target: x86_64-apple-darwin10.8.0 I have a test program written in UPC that takes a long time to compile on Mac OS X. This is caused by the var_tracking code that I think is getting erroneously enabled for no-optimization case - only -g option is used on a command line. When process_options (in toplevel.c) is called, flag_var_tracking has a value of 2 which is AUTODETECT_VALUE, and is getting set based on the optimization level: 1466 if (flag_var_tracking == AUTODETECT_VALUE) 1467 flag_var_tracking = optimize = 1; For x86_64 on Linux box this would set flag_var_tracking to 0. However, for Darwin, target_option.override is used and darwin_override_options() is called at the beginning of the process_options() and this code is getting executed (darwin.c): 2929 if (flag_var_tracking 2930 generating_for_darwin_version = 9 2931 (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE) 2932 : (debug_info_level = DINFO_LEVEL_NORMAL)) 2933 write_symbols == DWARF2_DEBUG) 2934 flag_var_tracking_uninit = 1; The above will set flag_var_tracking_uninit as all conditions are there: flag_var_tracking == 2 generating_for_darwin_version == 10 debug_info_level = DINFO_LEVEL_NORMAL write_symbols == DWARF2_DEBUG Once code returns to process_options: 1460 /* If the user specifically requested variable tracking with tagging 1461 uninitialized variables, we need to turn on variable tracking. 1462 (We already determined above that variable tracking is feasible.) */ 1463 if (flag_var_tracking_uninit) 1464 flag_var_tracking = 1; 1465 1466 if (flag_var_tracking == AUTODETECT_VALUE) 1467 flag_var_tracking = optimize = 1; flag_var_tracking is getting unconditionally set based debug level (not optimization). The net effect is that for Darwin, var_tracking is always enabled, even for the optim level of 0. If I specify -g -fvar-tracking on the Linux x86_64 box I also get long compile times on my test. I think that var_tracking needs to be disabled on -O0.
[Bug bootstrap/49739] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49739 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-07-14 02:59:50 UTC --- (In reply to comment #1) Created attachment 24752 [details] proposed patch Drats, I've missed that part of the i[34567]86-*-linux* case. Could you please try the attached patch. It's just a hack, but probably will have to do for now. It doesn't work and build failed much earlier: /export/gnu/import/git/gcc/gcc/fold-const.c -o fold-const.o /export/gnu/import/git/gcc/gcc/except.c: In function \u2018sjlj_emit_function_enter\u2019:/export/gnu/import/git/gcc/gcc/except.c:1116:7: warning: implicit declaration of function \u2018ASM_GENERATE_INTERNAL_LABEL\u2019 [-Wimplicit-function-declaration] /export/gnu/import/git/gcc/gcc/final.c: In function \u2018app_enable\u2019: /export/gnu/import/git/gcc/gcc/final.c:277:7: error: \u2018ASM_APP_ON\u2019 undeclared (first use in this function) /export/gnu/import/git/gcc/gcc/final.c:277:7: note: each undeclared identifier is reported only once for each function it appears in /export/gnu/import/git/gcc/gcc/final.c: In function \u2018app_disable\u2019: /export/gnu/import/git/gcc/gcc/final.c:290:7: error: \u2018ASM_APP_OFF\u2019 undeclared (first use in this function) /export/gnu/import/git/gcc/gcc/final.c: In function \u2018profile_functio
[Bug bootstrap/49739] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49739 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-07-14 03:01:15 UTC --- (In reply to comment #2) (In reply to comment #1) Created attachment 24752 [details] proposed patch Drats, I've missed that part of the i[34567]86-*-linux* case. Could you please try the attached patch. It's just a hack, but probably will have to do for now. It doesn't work and build failed much earlier: Patch is missing '}'.
[Bug bootstrap/49739] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49739 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-14 03:38:11 UTC --- Author: hjl Date: Thu Jul 14 03:38:06 2011 New Revision: 176261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176261 Log: Restore bootstrap on Linux/x86. 2011-07-13 Rainer Orth r...@cebitec.uni-bielefeld.de PR bootstrap/49739 * config.gcc (extra_parts): Add crtprec32.o crtprec64.o crtp rec80.o crtfastmath.o for Linux/x86. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
