[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- Comment #1 from Denis dot Excoffier at airbus dot com 2010-06-11 08:05 --- The same applies to mpfr-3.0.0 (now official). The MPFR people have however added the following note in ./INSTALL: > As gmp-impl.h and longlong.h are only in the GMP source directory, > you first need to copy these files to the build directory if it is > different (there may be other workarounds, such as setting $CPPFLAGS > to search the GMP source directory). This may be a better workaround than the one i proposed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug testsuite/25763] objc.dg/stubify-*.m, and obj-c++.dg/stubify-*.mm fail on i686-darwin
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-11 08:32 --- closing as fixed after back-porting to the 4.5 release branch at r160482 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25763
[Bug libgomp/42828] OpenMP executes unreliably when used in pthread.
--- Comment #2 from iains at gcc dot gnu dot org 2010-06-11 08:36 --- is this now fixed? in 4.5 after r160526, and trunk after r160457 which should have made the detection of emulated TLS more reliable. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42828
[Bug libgomp/42829] TLS detection in ./configure is wrong.
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 08:37 --- closing as fixed by r160457 (trunk) and r160526 (4.5 release branch) -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42829
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #77 from iains at gcc dot gnu dot org 2010-06-11 08:38 --- no new issues having been reported by the regression testers, closing this as fixed. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug fortran/32203] Support the vendor intrinsic function TIMEF
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-06-11 08:43 --- I remember discussing that a long while back, and I don't think people had strong opinions. WONTFIX seems good. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32203
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #17 from iains at gcc dot gnu dot org 2010-06-11 08:57 --- closing as fixed after back-ports to the current release branch (4.5) for various ObjC fixes including the ones listed here: r160482, r160541, r160546 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug c++/44499] New: No default constructor available
The following code:
class C {
};
class D : public C {
};
const D g_d;
fails to compile on trunk (rev. 160489) with the following message:
$ g++ test.cpp
test.cpp:11:9: error: uninitialized const 'g_d' [-fpermissive]
test.cpp:6:11: note: 'const class D' has no user-provided default constructor
--
Summary: No default constructor available
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
--- Comment #6 from iains at gcc dot gnu dot org 2010-06-11 09:10 --- @r160568 (or earlier) this is no longer showing. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug c++/44499] No default constructor available
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-11 09:26 --- gcc is correct, accepting the code previously was a bug that was fixed recently You need to provide an initializer for g_d -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-11 10:27 --- A question: apart from quoting chapter and verse from the standard (8.5 [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have been any clearer? It indicates you can use -fpermissive to relax the warning, and it includes a note telling you the type has no user-provided default constructor, which is true. Why would you assume this is a bug, when a developer has gone to the trouble of writing the note? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] New: Bogus narrowing conversion error
Compiling with g++ -std=c++0x, using gcc-4.5.0 :
struct A {
char x;
};
template void f() {
char y = 42;
A a = { y+C };
}
int main() {
f<1>();
}
yields an "error: narrowing conversion of â(((int)y) + 8)â from âintâ
to âcharâ inside { }".
If I change the template parameter type from "char C" to "int C" the error
message persists, this seems wrong too, but I am not quite shre.
If I leave out the "y", everything is fine.
--
Summary: Bogus narrowing conversion error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gpiez at web dot de
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug tree-optimization/44493] [4.6 Regression] ACATS cxg1004 unhandled expression in get_expr_operands at tree-ssa-operands.c:1020
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:47 --- Reduced testcase at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00131.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|ada |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 10:47:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44493
[Bug target/44494] [4.6 regression] Several SPARC testcases fail: invalid args to cas*
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-11 10:48 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 10:48:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44494
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n > 0
--- Comment #9 from aoliva at gcc dot gnu dot org 2010-06-11 10:49 --- Steve, lto and whopr seem to have been introduced in a way that broke VTA. This is not ia64-specific, and it's not what this bug is about. I guess what you're seeing are other cases of lossage, that we might have to look into, but it's better to open separate bugs for them, to avoid confusing the issue further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug c++/44499] No default constructor available
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-11 10:53 --- (In reply to comment #1) > gcc is correct, accepting the code previously was a bug that was fixed > recently > > You need to provide an initializer for g_d This sort of changes should be documented in the changes.html page or in porting_to.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-11 10:57 --- I wonder what the C++ standard said because we have the same issue in Wconversion and Joseph rejected my patch arguing that the operation was done in the larger type, so there was a narrowing conversion. I still believe that we should not warn for T = T op T, when T is the same type all the time. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44499] No default constructor available
--- Comment #4 from piotr dot wyderski at gmail dot com 2010-06-11 11:01 --- (In reply to comment #2) > A question: apart from quoting chapter and verse from the standard (8.5 > [dcl.init], para 9 in C++03, para 6 in C++0x,) how could the diagnostic have > been any clearer? > > It indicates you can use -fpermissive to relax the warning, and it includes a > note telling you the type has no user-provided default constructor, which is > true. Why would you assume this is a bug, when a developer has gone to the > trouble of writing the note? All the compilers I am aware of accept the aforementioned construction, so I blindly assumed that 4.6 is wrong in issuing a warning. The note's content was considered irrelevant, since no error was expected. But if the behaviour is OK, then it is OK no matter what a surprise it turns out to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-11 11:11 --- Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2 Copyright 1988-2008 Comeau Computing. All rights reserved. MODE:strict errors C++ C++0x_extensions "ComeauTest.c", line 9: error: const variable "g_d" requires an initializer -- class "D" has no explicitly declared default constructor const D g_d; ^ "ComeauTest.c", line 9: warning: variable "g_d" was declared but never referenced const D g_d; ^ 1 error detected in the compilation of "ComeauTest.c". I think the error message of comeau is better (but our note is better). I will write a patch. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
-- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 11:11:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44499] No default constructor available
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-11 11:13 --- LLVM is still using GCC in their demo, not Clang. So I cannot test their output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44499
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #2 from gpiez at web dot de 2010-06-11 11:34 ---
Sorry for the unicode mess. The error message is 'error: narrowing conversion
of "(((int)y) + 1)" from "int" to "char" inside { }'.
The same error happens with a non templated function, but if I use two template
parameters, the error disappears, even if they are to large. So this is at
least very inconsistent.
no error:
struct A {
<-->char x;
};
templatevoid f() {
<-->A a = { C+D };
}
int main() {
<-->f<1,2>();
}
still no error:
struct A {
<-->char x;
};
templatevoid f() {
<-->A a = { C+D };
}
int main() {
<-->f<1,2>();
}
error:
struct A {
<-->char x;
};
void f(char C, char D) {
<-->A a = { C+D };
}
int main() {
<-->f(1,2);
}
I believe I should not get an error, even if the template parameter type is
larger than a char, as long as the template parameter value fits in in char, so
template void f() {
char y = 42;
A a = { y+C };
}
should give no error, as long as C fits in a char. IMHO ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-11 11:37 --- 'y' and 'C' are both promoted to int and 'y' is not a constant, so the resulting value cannot be proven to fit in a char, so it's a narrowing conversion. If you make 'y' a const int then the value y+C is a constant and can be proven not to narrow. The fact that the optimiser knows y=42 is irrelevant, the language specifies that y is not a constant, and whether the code is valid or not has to be independent of optimisations such as value propagation. I think gcc is correct here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-11 11:42 ---
(In reply to comment #2)
> Sorry for the unicode mess. The error> I believe I should not get an error,
> even if the template parameter type is
> larger than a char, as long as the template parameter value fits in in char,
> so
>
> template void f() {
> char y = 42;
> A a = { y+C };
> }
>
> should give no error, as long as C fits in a char. IMHO ;-)
Just to be extra clear: C is a constant and the narrowing is *not* due to C,
consider:
struct A {
char x;
};
template void f() {
A a = { C };
}
int main() {
f<1>();
}
Here C is an int, but it's a constant and it is provable that no narrowing
takes palce.
The problem in your example is 'y' not 'C' because the value of 'y' is not a
constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug debug/43222] two DEBUG i => 0 generated after loop copy header
--- Comment #7 from aoliva at gcc dot gnu dot org 2010-06-11 11:45 --- Not a bug -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43222
[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries
--- Comment #10 from ro at gcc dot gnu dot org 2010-06-11 11:46 --- Subject: Bug 44216 Author: ro Date: Fri Jun 11 11:45:59 2010 New Revision: 160602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160602 Log: Backport from mainline: 2010-05-25 Rainer Orth PR libgcj/44216 * configure.ac (libgcj_cv_exidx): Enable AC_LANG_WERROR. Save and restore werror flag. * configure: Regenerate. Modified: branches/gcc-4_5-branch/libjava/ChangeLog branches/gcc-4_5-branch/libjava/configure branches/gcc-4_5-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries
--- Comment #11 from ro at gcc dot gnu dot org 2010-06-11 11:49 --- Subject: Bug 44216 Author: ro Date: Fri Jun 11 11:49:16 2010 New Revision: 160603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160603 Log: config: * override.m4 (AC_LANG_WERROR): Redefine to autoconf 2.62 version. libjava: Backport from mainline: 2010-05-25 Rainer Orth PR libgcj/44216 * configure.ac (libgcj_cv_exidx): Enable AC_LANG_WERROR. Save and restore werror flag. * configure: Regenerate. Modified: branches/gcc-4_4-branch/config/ChangeLog branches/gcc-4_4-branch/config/override.m4 branches/gcc-4_4-branch/libjava/ChangeLog branches/gcc-4_4-branch/libjava/configure branches/gcc-4_4-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44216
[Bug fortran/44497] [4.6 Regression] gfortran.dg/maxlocval_2.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
[Bug libgomp/44498] [4.6 Regression] Many libgomp failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
[Bug java/44495] [4.6 regression] ICE in java_mangle_resource_name, at java/mangle.c:658
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44495
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #5 from gpiez at web dot de 2010-06-11 12:09 --- So is it provable that for a "T op T" to be stored in T no narrowing takes place? If the answer for T == char is no and for T == int it is yes this is rather fishy ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:23 --- Created an attachment (id=20887) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20887&action=view) Patch that fixes the problem Here's the patch I'm testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 --- *** Bug 44247 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug middle-end/44247] -fcompare-debug failure with -O1 -fgraphite-identity
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-06-11 12:28 --- The patch for bug 44181 fixes this one as well. *** This bug has been marked as a duplicate of 44181 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44247
[Bug fortran/44497] [4.6 Regression] gfortran.dg/maxlocval_2.f90
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 12:43 --- (In reply to comment #2) > It could be a dup of PR 44498. It if does not turn out to be a dup of the bitmap work / PR 44498, we need a backtrace or valgrind trace (with minimal options, e.g. -O0 if possible). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44497
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-11 12:51 ---
(In reply to comment #5)
> So is it provable that for a "T op T" to be stored in T no narrowing takes
> place?
Yes, if the values are constants.
> If the answer for T == char is no and for T == int it is yes this is rather
> fishy ;-)
That's not what I said. Look:
#include
struct A {
char x;
};
template void f() {
A a = { C+D };
}
template void g() {
A a = { I+J };
}
int main() {
f<1, 1>();// OK
g<1, 1>();// OK
f(); // Error
}
f<1,1>() is ok, because C and D are constants. The type doesn't matter, the
result of C+D is known at compile time and fits in a char.
g<1,1>() is ok, because I and J are constants. The type doesn't matter, the
result of I+J is known at compile time and fits in a char.
f() is not ok, because the result is known at compile time
and doesn't fit in a char.
See 8.5.4 [dcl.init.list]p6 in teh C++0x draft for the full rules
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug debug/44181] -fcompare-debug failure (length) with -Os -fgraphite-identity
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 --- *** Bug 43650 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44181
[Bug tree-optimization/43650] "-fcompare-debug failure" with "-O2 -fpeel-loops -fgraphite-identity"
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-06-11 12:56 --- Unlike PR43656, this one is also fixed by the patch proposed for PR44181. *** This bug has been marked as a duplicate of 44181 *** -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43650
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-11 13:07 ---
He is referring to a testcase like:
template void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
f();
f();
}
So, we warn for T == char but not for T == int. I know that the standard
considers differently narrowing and overflow but the difference is still
surprising.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug fortran/30677] Intrinsics arguments evaluated multiple times
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-02 08:00:41 |2010-06-11 13:17:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30677
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-11 13:20 ---
(In reply to comment #7)
> He is referring to a testcase like:
>
> template void f() {
> struct A {
> T x;
> };
>
> T y = 42;
> A a = { y + C };
> }
>
> int main() {
> f();
> f();
> }
>
> So, we warn for T == char but not for T == int. I know that the standard
Note it's not a warning, it's an error, mandated by the standard.
> considers differently narrowing and overflow but the difference is still
> surprising.
In both cases, T+T has type int, so obviously it fits in an int. It doesn't
necessarily fit in an char, so is an error unless the values are constants and
the actual value can fit in a char.
This is mandated by the standard and the diagnostic is IMHO clear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug middle-end/44492] auto-inc-dec pushes PRE_MODIFY/PRE_INC into inline asm operands
--- Comment #22 from jakub at gcc dot gnu dot org 2010-06-11 13:22 --- Created an attachment (id=20888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20888&action=view) gcc46-pr44492.patch Updated patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20883|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
[Bug c/44501] New: Wrong register stored
Hello,
it seems if there is a bug in the avr 32 gcc compiler.
avr32-gcc: version 4.3.2
toolchain: avr32-gnu-toolchain-2.4.2-setup.exe
avr32studio: avr32studio-ide-installer-2.5.0.35-win32.win32.x86.exe
Both got from www.atmel.com
Device: UC3B0256
Compilerflags: -O2 -g2 -mpart=uc3b0256
When compiling the atached example whith optimation "O2" the line:
telegramm[10] = 1;
won't be translated right.
In the listfile I see, that the wrong register will be stored to
"telegramm[10]".
Listfile:
telegramm[10] = 1;
811a: 30 1a mov r10,1
void test_func(u8_t port)
{
u8_t *telegramm = test_str[port].telegramm_tx;
telegramm[6] = 33;
811c: b8 e9 st.b r12[0x6],r9
telegramm[10] = 1;
811e: f9 68 00 0a st.b r12[10],r8
It will store r8 instead of r10, which has got the 1.
I don't know if you coult help me, because the gcc ported from Atmel?
I have attached the test code, the listfile and the output of
avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c.
(hope I can attach them after commit)
--
Summary: Wrong register stored
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland dot cassebohm at dh-partner dot com
GCC host triplet: i686-pc-cygwin
GCC target triplet: avr32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #9 from gpiez at web dot de 2010-06-11 13:27 ---
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it shouldn't give an error, and if the
standard says so, I think it is flawed in this regard ;-)
Consider
g(); // Warning, but no Error
despite it can be proven that the value will not fit and this is very likely an
error. Opposing to
char c,d;
A a = { c+d };
which is very likely not an error and would only require a mild warning. IMHO.
Manuel, in your testcase, you do not only warn, you error out if compiled with
-std=c++0x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c/44501] Wrong register stored
--- Comment #1 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:27 --- Created an attachment (id=20889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20889&action=view) Test program This file could be compiled alone with avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c/44501] Wrong register stored
--- Comment #2 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:29 --- Created an attachment (id=20890) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20890&action=view) Listfile with resulted assembler Generated with: avr32-objdump.exe -S main.o > main.lst -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c/44501] Wrong register stored
--- Comment #3 from roland dot cassebohm at dh-partner dot com 2010-06-11 13:31 --- Created an attachment (id=20891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20891&action=view) gcc output Output of avr32-gcc by using: avr32-gcc -v -save-temps -O2 -g3 -mpart=uc3b0256 -c main.o main.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-11 13:33 ---
(In reply to comment #8)
>
> In both cases, T+T has type int,
We know that, but I don't think most C/C++ programmers know about integer
promotion rules. We just disagree here. But since this is mandated by the
standard, you are right.
> so obviously it fits in an int. It doesn't
For a strict-standard definition of "fits", because it may overflow and a
layman wouldn't say that it "fits" in that case.
> This is mandated by the standard and the diagnostic is IMHO clear.
I am not arguing against that (although, I think it is unfortunate). I would
prefer a bit longer message:
error: C++0x does not allow narrowing conversion of "(((int)y) + 1)" from "int"
to "char" inside { }
(BTW, I think those braces should be within quotes).
But since I guess I am in the minority here, we'll have to close this as
INVALID.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug target/44501] Wrong register stored
-- roland dot cassebohm at dh-partner dot com changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:38 --- (In reply to comment #2) > Still true for gcc version 4.6.0 20100509 (experimental) (GCC) I don't know if it's worth the extra work, but this can be tackled in gfc_conv_substring() by checking whether start.expr and end.expr refer to the same var_decl (stripping conversions). If they do, the length is one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug fortran/42042] Symbol __x86_64__ no longer defined?
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 13:46:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42042
[Bug fortran/41897] Support TR 29113: "Further Interoperability of Fortran with C"
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 13:47:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
[Bug fortran/43837] Set TREE_NOTHROW also on libgfortran library calls
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 13:47:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43837
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:51 --- > if(atan(1.0, i/10.0) -atan2(1.0, i/10.)/= 0.0) call abort() Try to change that into a "print *, atan(1.0, i/10.0) -atan2(1.0, i/10.)" and see what it outputs. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug fortran/33584] FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error)
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2010-06-11 13:52 --- OK, so I suppose the test is a bit extreme, but other than that, I vote for WONTFIX (or INVALID). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
[Bug debug/43656] "-fcompare-debug failure" with "-O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity"
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-11 13:57 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
[Bug fortran/41897] Support TR 29113: "Further Interoperability of Fortran with C"
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-11 13:58 --- Latest draft: ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1808.pdf Time line: ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1812.txt (-> 2nd draft: 2010-10) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
[Bug debug/43656] "-fcompare-debug failure" with "-O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity"
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-06-11 14:00 --- Created an attachment (id=20892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20892&action=view) Patch that fixes the problem This patch (perhaps in addition to the patch for PR 44181, I haven't tried the old tree without that patch) fixes sched to disregard any apparent register pressure from debug insns. I'm going to give it some more testing before posting it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
[Bug middle-end/42255] [4.3 Regression] broken generated code when using -fprofile-arcs and -O2
--- Comment #6 from gael dot guennebaud at gmail dot com 2010-06-11 14:05 --- Created an attachment (id=20893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20893&action=view) A new test case preprocessed with gcc 4.3.4 for -fno-guess-branch-probability Hi, here is a new test case showing a very similar issue when compiling with -O2 only. To be crystal clear, when compiling this example with -O2 only, then the program returns the error: Test cwiseops(Matrix()) failed in "/home/gael/Coding/eigen2/test/cwiseop.cpp" (80) test_ei_isApprox(m4.setConstant(s1), m3) and valgrind report a "Use of uninitialised value of size 8". On the other hand, when compiling with "-O2 -fno-guess-branch-probability", then the program terminates fine, and valgrind report no error. Since the -fguess-branch-probability optimization seems to be related to -fprofile-arcs, I believe both examples exhibits the same bug. I hope that helps. Also, this example (as the previous one) works fine with gcc 3.4, 4.0.1, 4.1, 4.2, 4.4, 4.5, Intel's ICC, and various versions of MSVC. -- gael dot guennebaud at gmail dot com changed: What|Removed |Added Attachment #19210|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
[Bug target/44501] Wrong register stored
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44501
[Bug c/44502] New: Bogus diagnostic: format '%u' expects type 'unsigned int', but argument 2 has type 'unsigned int'
When passing the result of __builtin_bswap32() to printf() and -Wformat is
enabled, the following code:
#include
int foo(unsigned int arg) {
return printf("%u", __builtin_bswap32(arg));
}
generates this odd diagnostic:
foo.c:3: warning: format '%u' expects type 'unsigned int', but argument 2 has
type 'unsigned int'
Strangely enough, if I use "%d" instead of "%u", no diagnostic is generated.
I haven't checked the details of __builtin_bswap32()'s implementation, but I
wonder if this might be the same issue as (or related to) bug 21962?
--
Summary: Bogus diagnostic: format '%u' expects type 'unsigned
int', but argument 2 has type 'unsigned int'
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla1 at achurch dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44502
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
--- Comment #4 from tromey at gcc dot gnu dot org 2010-06-11 14:53 --- I think the problem with this patch is that it leaves gdb no way to determine which approach it should use. This is important because there is a lot of existing code compiled with the incorrect approach. Currently gdb has a heuristic where it uses the incorrect style if it sees DW_AT_containing_type in the virtual function's DIE. This appears to be a GNU extension (you can see it at the end of the patch, in the context -- but there is another instance in dwarf2out.c). Maybe removing that would help. I'm not sure if it is needed and/or useful for some other reason, maybe a little exploration of the history would help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
[Bug c++/44500] [C++0x] Bogus narrowing conversion error
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-11 14:56 ---
(In reply to comment #9)
> I understand now after the implicit promotion to int of a non constant value
> the result of the narrowing operation can't be guaranteed to fit in the
> original type. But I still think it shouldn't give an error, and if the
> standard says so, I think it is flawed in this regard ;-)
>
> Consider
>
> g(); // Warning, but no Error
The integer overflow means this is undefined behaviour. But it is not a
narrowing conversion according to the rules of 8.5.4/6
> despite it can be proven that the value will not fit and this is very likely
> an
> error. Opposing to
>
> char c,d;
> A a = { c+d };
>
> which is very likely not an error and would only require a mild warning. IMHO.
use A a = { char(c+d) } if you want the result to be a char not an int, then
there is no narrowing conversion, because a narrowing conversion is an impliit
conversion.
(In reply to comment #10)iagnostic is IMHO clear.
> prefer a bit longer message:
>
> error: C++0x does not allow narrowing conversion of "(((int)y) + 1)" from
> "int"
> to "char" inside { }
I prefer the shorter message. If the compiler tells you there is an error it
doesn't normally tell you the standard says so. If you compile with -std=c++0x
then obviously that's the standard in question.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
[Bug c/37743] Bogus printf format warning with __builtin_bswap32.
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-11 14:56 --- *** Bug 44502 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcczilla1 at achurch dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
[Bug c/44502] Bogus diagnostic: format '%u' expects type 'unsigned int', but argument 2 has type 'unsigned int'
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-11 14:56 --- *** This bug has been marked as a duplicate of 37743 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44502
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
--- Comment #5 from tromey at gcc dot gnu dot org 2010-06-11 15:07 --- Jakub pointed out that gdb can just look for an isolated DW_OP_constu to fall back to the old code. I will write a gdb patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #9 from redi at gcc dot gnu dot org 2010-06-11 15:32 --- Subject: Bug 44268 Author: redi Date: Fri Jun 11 15:31:53 2010 New Revision: 160617 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160617 Log: 2010-06-11 Jonathan Wakely PR libstdc++/44268 * doc/xml/manual/abi.xml: Fix libgcc version for hppa-linux. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/abi.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-11 15:35 --- fixed (but website not updated with the changes yet) -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug debug/43656] "-fcompare-debug failure" with "-O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity"
--- Comment #7 from zsojka at seznam dot cz 2010-06-11 16:10 --- I can confirm the testcase from comment #3 doesn't fail in r158095 when only patch from comment #6 is applied (and gcc_checking_assert() is replaced by gcc_assert()) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 16:27 --- For completeness, also Cray Fortran 7.2.3 prints: A WRITE operation is invalid if the file is positioned after the end-of-file. Updated summary: - Error with: NAG f95 v5.1, Pathscale pathf95 3.2.99, Cray ftn 8.2.3, Open64 4.2 - No error with: ifort 11.1, gfortran, g95, sunf95 8.3 (sunstudio12), Portland's pgf90 v6.2 and v10.3. - Unknown: g77, ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug c/44503] New: "control flow in the middle of basic block" with -fprefetch-loop-arrays
Attached is a test case from gcc regression test. verify_flow_info failed when I turned on prefetching. gcc -O3 -fprefetch-loop-arrays setjmp-1.c setjmp-1.c: In function main: setjmp-1.c:17:1: error: control flow in the middle of basic block 20 setjmp-1.c:17:1: error: control flow in the middle of basic block 20 setjmp-1.c:17:1: internal compiler error: verify_flow_info failed Please submit a full bug report, Looks like loops with longjmp should not be unrolled. -- Summary: "control flow in the middle of basic block" with - fprefetch-loop-arrays Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: changpeng dot fang at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503
[Bug c/44503] "control flow in the middle of basic block" with -fprefetch-loop-arrays
--- Comment #1 from changpeng dot fang at amd dot com 2010-06-11 16:32 --- Created an attachment (id=20894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20894&action=view) prefetching for the while loop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #19 from janus at gcc dot gnu dot org 2010-06-11 16:46 --- Subject: Bug 43896 Author: janus Date: Fri Jun 11 16:45:48 2010 New Revision: 160622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622 Log: 2010-06-11 Paul Thomas PR fortran/42051 PR fortran/43896 * trans-expr.c (gfc_conv_derived_to_class): Handle array-valued functions with CLASS formal arguments. 2010-06-11 Paul Thomas PR fortran/42051 PR fortran/43896 * gfortran.dg/class_23.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_23.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/44504] New: DEALLOCATE aborts program even with STAT=
Using built-in specs. Target: x86_64-apple-darwin10.3.0 Configured with: ../gcc-4.4.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.4/info --enable-languages=c,c++,fortran,objc,obj-c++ --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.4 Thread model: posix gcc version 4.4.4 (GCC) Consider this program: program deallocate_test integer, pointer :: p1,p2,a integer :: ios allocate (a) p1 => a p2 => a write (*,*) 'Deallocate p1' deallocate (p1, stat=ios) write (*,*) 'status = ',ios write (*,*) 'Deallocate p2' deallocate (p2, stat=ios) write (*,*) 'status = ',ios end program deallocate_test The result is: Deallocate p1 status =0 Deallocate p2 deallocate_test(68227) malloc: *** error for object 0x100200b60: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap There should NOT be an abort even though, indeed, p2 cannot be deallocated. The value ios should simply be non-zero. This result seems to be an overzealous reaction to bug #35718 which reported that DEALLOCATE (..., STAT=...) always returned 0. -- Summary: DEALLOCATE aborts program even with STAT= Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: remko dot scharroo at me dot com GCC build triplet: x86_64-apple-darwin10.3.0 GCC host triplet: x86_64-apple-darwin10.3.0 GCC target triplet: x86_64-apple-darwin10.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-11 16:46 --- Subject: Bug 42051 Author: janus Date: Fri Jun 11 16:45:48 2010 New Revision: 160622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622 Log: 2010-06-11 Paul Thomas PR fortran/42051 PR fortran/43896 * trans-expr.c (gfc_conv_derived_to_class): Handle array-valued functions with CLASS formal arguments. 2010-06-11 Paul Thomas PR fortran/42051 PR fortran/43896 * gfortran.dg/class_23.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_23.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-06-11 16:49 --- When I tried the LTO step in any of the two testcases I got: jamb...@tuc:~/gcc/mine/test/pr44464$ ~/gcc/inst/mine/bin/gcc -r -fwhopr igmp.mini.o /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status What am I doing wrong? (And what does the -r switch, I can't find it in the documentation) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-11 16:50 --- Fixed with r160622. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-11 17:09 --- Sorry you need -nostdlib too (forgot that) -r is immediate linking -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug libgomp/44498] [4.6 Regression] Many libgomp failures
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-11 17:48 --- For the record revision 160549 also broke boostrap on x86_64-apple-darwin10.3.0 near the end of stage 2: echo CRTSTUFF_T_CFLAGS = '' >> tmp-libgcc.mvars echo CRTSTUFF_T_CFLAGS_S = '' >> tmp-libgcc.mvars echo TARGET_SYSTEM_ROOT = '' >> tmp-libgcc.mvars mv tmp-libgcc.mvars libgcc.mvars ../../work/gcc/config/i386/i386.md: In function 'internal_dfa_insn_code': ../../work/gcc/config/i386/i386.md:358:1: internal compiler error: Segmentation fault Since it is now fixed with revision 160612, I don't see the point to fill an obvious duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44498
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-11 18:04 ---
I think this is a bug in your program:
allocate (a) ! Allocate memory
p1 => a
p2 => a
! All of {a, p1, p2} point to the same memory.
deallocate (p1, stat=ios)
! Free memory pointed to by {a, p1, p2}
! and mark "p1" as disassociated / not-allocated
!
! p2 and a have the pointer-association status "undefined"
deallocate (p2, stat=ios)
! Invalid: Access to pointer with "undefined" pointer association status.
Or to put into standard speech: http://gcc.gnu.org/wiki/GFortranStandards
"A pointer may have a pointer association status of associated, disassociated,
or undefined. Its association status may change during execution of a program.
Unless a pointer is initialized (explicitly or by default), it has an initial
association status of undefined. A pointer may be initialized to have an
association status of disassociated or associated."
"16.5.2.5 Events that cause the association status of pointers to become
undefined":
"(3) the target of the pointer is deallocated other than through the pointer,"
And finally:
"A pointer that is not associated shall not be referenced or defined."
and
"If a pointer appears in a DEALLOCATE statement, its association status shall
be defined."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-11 18:12 --- Reset several to 'normal'. Fortran bugs are never 'major'. I believe your code is invalid, and so gfortran can do anything it wants. F2003 has 19 6.3.3.2 Deallocation of pointer targets If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, the pointer shall not be deallocated. If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation. Deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target or a portion of the target to become undefined. Your statement "deallocate (p1, stat=ios)" causes p2 to become undefined. Thus, your statement "deallocate (p2, stat=ios)" violates the first sentence in this section. Of course, I could be wrong. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22 --- I fully agree that the second "deallocate (p2, stat=ios)" is a violation. That is the actual intend of this program. You know, this is not arbitrary code. You can often have multiple pointers pointing to allocated memory, and then you want to deallocate the memory. Then you need to do multiple "deallocate" statements. You cannot do it any other way, since you cannot test "if (allocated)" since the pointer is not "allocatable". Therefore, the best try is to simply deallocate all the pointers, i.e., "deallocate (p2, stat=ios)" Reading your excerpt from the F2003 standards, it does, of course, shows the violation. But then I expect ios simply to be non-zero, not get an abort. For example, I read in Stephan J. Chapman "Fortran 90/95 for scientists and engineers", p 635 "If the pointer in the statement happens to point to a target not created with an ALLOCATE statement, then the DEALLOCATE statement fails and the program aborts UNLESS THE STAT= CLAUSE WAS SPECIFIED" (emphasis is mine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug rtl-optimization/44481] [4.3/4.4/4.5/4.6 Regression] __builtin_parity() causes ICE in trunc_int_for_mode()
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-11 18:24 --- It is caused by revision 121863: http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00421.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||uros Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-11 18:24:48 date|| Summary|__builtin_parity() causes |[4.3/4.4/4.5/4.6 Regression] |ICE in trunc_int_for_mode() |__builtin_parity() causes ||ICE in trunc_int_for_mode() Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #6 from spop at gcc dot gnu dot org 2010-06-11 18:28 --- Subject: Bug 44483 Author: spop Date: Fri Jun 11 18:28:17 2010 New Revision: 160625 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160625 Log: Fix PR44483: incrementally gimplify BB predicates to avoid redundant computations. 2010-06-11 Sebastian Pop PR middle-end/44483 * tree-if-conv.c (bb_predicate_s): New struct. (bb_predicate_p): New. (bb_has_predicate): New. (bb_predicate): New. (set_bb_predicate): New. (bb_predicate_gimplified_stmts): New. (set_bb_predicate_gimplified_stmts): New. (add_bb_predicate_gimplified_stmts): New. (init_bb_predicate): New. (free_bb_predicate): New. (is_predicated): Use bb_predicate. (add_to_predicate_list): Use bb_predicate and set_bb_predicate. (predicate_bbs): Same. Gimplify the condition of the basic blocks before processing their successors. (clean_predicate_lists): Removed. (find_phi_replacement_condition): Use bb_predicate. (process_phi_nodes): Renamed ifconvert_phi_nodes. Avoid useless computations. (insert_gimplified_predicates): New. (combine_blocks): Call insert_gimplified_predicates. (tree_if_conversion): Call free_bb_predicate instead of clean_predicate_lists. * gcc.dg/tree-ssa/pr44483.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44483.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #7 from spop at gcc dot gnu dot org 2010-06-11 18:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug tree-optimization/44503] "control flow in the middle of basic block" with -fprefetch-loop-arrays
--- Comment #2 from changpeng dot fang at amd dot com 2010-06-11 18:45 --- Bug 39398 looks similar but that one seems with except handling instead of setjmp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44503
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-11 19:54 --- (In reply to comment #3) > I fully agree that the second "deallocate (p2, stat=ios)" is a violation. > That is the actual intend of this program. Well, I can also complain that fhjdshlkgjflsg end does not calculate PI - but why should it? If a program is invalid, everything can happen! > Reading your excerpt from the F2003 standards, it does, of course, shows the > violation. But then I expect ios simply to be non-zero, not get an abort. Like most Fortran compilers, gfortran does not track the allocation. It simply checks: Is the pointer a NULL pointer, if not - free it. Then, the C library tells the operating system that the memory is no longer needed. If you know access the memory (reading or writing), the operating system has to stop you from doing so. (Otherwise, you could widely modify the memory belonging to other users.) And it does so by killing your program. Sometimes, also the C library does some checking by keeping track of which variables are allocated or not. But gfortran does not add another layer on top of it to keep track of all allocated variables. That is simply to expensive (computationally but also in implementing it). Thus, if you do something invalid of this kind, the program will be killed > For example, I read in Stephan J. Chapman "Fortran 90/95 for scientists and > engineers", p 635 "If the pointer in the statement happens to point to a > target not created with an ALLOCATE statement, then the DEALLOCATE statement > fails and the program aborts UNLESS THE STAT= CLAUSE WAS SPECIFIED" > (emphasis is mine). Well, but that's a different case: The pointer is in a well-defined state (namely it is associated). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug target/44481] [4.3/4.4/4.5/4.6 Regression] __builtin_parity() causes ICE in trunc_int_for_mode()
--- Comment #2 from ubizjak at gmail dot com 2010-06-11 19:54 --- Generic parts do not like parity in CCmode. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Component|rtl-optimization|target Last reconfirmed|2010-06-11 18:24:48 |2010-06-11 19:54:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
[Bug target/44481] [4.3/4.4/4.5/4.6 Regression] __builtin_parity() causes ICE in trunc_int_for_mode()
--- Comment #3 from ubizjak at gmail dot com 2010-06-11 19:55 --- Created an attachment (id=20895) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20895&action=view) Patch to fix the failure. Patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
--- Comment #6 from tromey at gcc dot gnu dot org 2010-06-11 20:02 --- Ok, I committed the gdb change: http://sourceware.org/ml/gdb-patches/2010-06/msg00287.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #12 from hp at gcc dot gnu dot org 2010-06-11 20:07 --- (In reply to comment #11) > (In reply to comment #10) > > Now (with r160560) appearing for cris-elf too! > > Forgot to mention that it last worked for cris-elf with r160547. Last known appearance r160602, gone again at r160612. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2010-06-11 20:16 --- Subject: Re: DEALLOCATE aborts program even with STAT= On Fri, Jun 11, 2010 at 06:22:57PM -, remko dot scharroo at me dot com wrote: > > > --- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22 > --- > I fully agree that the second "deallocate (p2, stat=ios)" is a violation. > That is the actual intend of this program. > You know, this is not arbitrary code. You can often have multiple pointers > pointing to allocated memory, and then you want to deallocate the memory. > Then you need to do multiple "deallocate" statements. > You cannot do it any other way, since you cannot test "if (allocated)" since > the pointer is not "allocatable". > Therefore, the best try is to simply deallocate all the pointers, i.e., > "deallocate (p2, stat=ios)" You deallocate the memory once and nullify the pointers. program deallocate_test integer, pointer :: p1,p2,a integer :: ios allocate (a) p1 => a p2 => a print *, associated(a), associated(p1), associated(p2) deallocate (a, stat=ios) p1 => null() p2 => null() print *, associated(a), associated(p1), associated(p2) end program deallocate_test The text from the F2003 standard that I quoted is neither a constraint or restriction on the fortran processor. It is a prohibition on the programmer. I don't have any other F2003 compiler available to me. What happens if you compile your code with other compilers? > Reading your excerpt from the F2003 standards, it does, of course, shows the > violation. But then I expect ios simply to be non-zero, not get an abort. That's an unrealistic expectation. You've violated the standard, which allows a compiler to anything (including what you expect). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #13 from sje at cup dot hp dot com 2010-06-11 20:19 --- On hppa2.0w-hp-hpux11.11, I don't see the testsuite failure after 158397. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
--- Comment #17 from manu at gcc dot gnu dot org 2010-06-11 20:22 --- The patch was rejected but it may be accepted by using a new -Wno-* option to disable these warnings. Perhaps -Wno-conversion-after-promotion? Suggestions are welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-06-11 20:27 --- (In reply to comment #3) > (In reply to comment #2) > > Still true for gcc version 4.6.0 20100509 (experimental) (GCC) > > I don't know if it's worth the extra work, but this can be tackled in > gfc_conv_substring() by checking whether start.expr and end.expr refer to the > same var_decl (stripping conversions). If they do, the length is one. This is one example where more powerful simplifications could help. I'm opening a separate PR for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-06-11 20:34
---
> [...@gnu-12 gcc]$ ./xgcc -B./ -O
> /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr42461.c
> /tmp/ccmdb99H.o: In function `main':
> pr42461.c:(.text+0x22): undefined reference to `link_failure'
> collect2: ld returned 1 exit status
> [...@gnu-12 gcc]$ ./xgcc -B./ -O2
> /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr42461.c
> [...@gnu-12 gcc]$
At -O we run only a stand-alone DCE pass after reload, which is also after at
least one splitting pass. Now the ia64 back-end splits calls and this drops
the RTL_PURE_CALL_P flag. There is a comment about this in ia64.md:
;; Irritatingly, we don't have access to INSN within the split body.
;; See commentary in ia64_split_call as to why these aren't peep2.
(define_split
[(call (mem (match_operand 0 "call_operand" ""))
(const_int 1))
(clobber (match_operand:DI 1 "register_operand" ""))
(clobber (match_scratch:DI 2 ""))
(clobber (match_scratch:DI 3 ""))]
"reload_completed && find_reg_note (insn, REG_NORETURN, NULL_RTX)"
[(const_int 0)]
{
ia64_split_call (NULL_RTX, operands[0], operands[1], operands[2],
operands[3], true, false);
DONE;
})
Therefore, the DCE pass doesn't see that the call is actually pure. At -O2 we
run a DCE pass just before combine. I'm going to adjust the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug middle-end/44505] New: [4.6 Regression] gcc.c-torture/execute/frame-address.c
On Linux/ia32, revision 160623 gave: FAIL: gcc.c-torture/execute/frame-address.c execution, -O2 FAIL: gcc.c-torture/execute/frame-address.c execution, -O3 -g FAIL: gcc.c-torture/execute/frame-address.c execution, -Os FAIL: gcc.c-torture/execute/frame-address.c execution, -O2 -flto FAIL: gcc.c-torture/execute/frame-address.c execution, -O2 -fwhopr Revision 160612 is OK. -- Summary: [4.6 Regression] gcc.c-torture/execute/frame-address.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-06-11 20:51 --- Subject: Bug 42461 Author: ebotcazou Date: Fri Jun 11 20:50:46 2010 New Revision: 160632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160632 Log: PR rtl-optimization/42461 * gcc.dg/pr42461.c: Compile at -O2 instead of -O. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr42461.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
--- Comment #4 from zsojka at seznam dot cz 2010-06-11 21:02 --- When rp() is declared with __attribute__((pure)), it fails even with -fno-ipa-pure-const. (still fails in r160527) I don't know if this is a bug or if this behaviour is fine according to standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43784
