[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #74 from fxcoudert at gcc dot gnu dot org 2007-03-03 08:52 --- (In reply to comment #73) I've added PR 31021 to track some performance issue with gfortran on one of CP2K's kernels. Thanks for your work, Joost. I wonder if you have done OpenMP testing, also (I imagine that, OpenMP being frequently broken on cp2k and gfortran being a free compiler OpenMP-capable, you might have tried it :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30885] [4.1 only] ICE: Segmentation Fault in gfortran
-- 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 |2007-03-03 09:56:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30885
[Bug fortran/30885] [4.1 only] ICE: Segmentation Fault in gfortran
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-03 09:57 --- Confirmed, but unless it's a regression for gfortran-4.0, it won't be fixed on the 4.1 branch. It's already fixed on 4.2 and above, and it's not a regression wrt g77. -- 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=30885
[Bug fortran/30998] Big code with assigned goto's loops with optimization
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30998
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #75 from jv244 at cam dot ac dot uk 2007-03-03 10:12 --- Joost. I wonder if you have done OpenMP testing, also (I imagine that, OpenMP being frequently broken on cp2k and gfortran being a free compiler OpenMP-capable, you might have tried it :) No, haven't tried it yet. So far I have had relatively little interest in openmp, because the openmp bits in CP2K are really few, and really bad... mainly because our focus is on massively parallel. However, things are changing quickly on that front as well, and we'll soon have a 8 cpu x 2 core (AMD) shared memory machine for experimenting a bit more seriously with this (among other things). One issue with OpenMP is that it is very easy to break an OpenMP code (it is just comments), unless you force all developers to always compile the openmp version as well (or you add one more automatic tester). The other thing is that some of the mistakes one can make with openmp easily (such as a forgotten critical section) only trigger bugs from time to time, e.g. depending on how threads are scheduled. Anyway, many excuses to say 'not really, but maybe soon'... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30941] intrinsic: FLUSH
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-03 10:22 --- For what it's worth, here's my opinion: we don't want to have a zillion of different versions of each library function. It might be worth doing for functions that are expected to be called in hot spots of the user code, but not for FLUSH, EXIT and other such intrinsics. So, it would be better to agree once and for all on a reasonnable choice of kind, depending on the use done for the intrinsic, and implementing and documenting this. I think in the case of FLUSH, there's an easy choice for the kind of UNIT. The unit numbers are always, in the I/O library, of kind=4 (see libgfortran.h, struct st_parameter_common). -- 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 |2007-03-03 10:22:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30941
[Bug fortran/30947] intrinsic: ALARM
-- 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 |2007-03-03 10:23:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30948] intrinsic: CHDIR
-- 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 |2007-03-03 10:23:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30950] intrinsic: CPU_TIME
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-03 10:24 --- Confirmed. I think CPU_TIME is a standard intrinsic, what is the standard name for its argument? -- 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 |2007-03-03 10:24:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30950
[Bug fortran/30932] [meta-bug] fortran intrinsics
-- 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 |2007-03-03 10:24:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30932
[Bug fortran/30953] intrinsic: CTIME
-- 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 |2007-03-03 10:24:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30950] intrinsic: CPU_TIME
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-03 10:28 --- what is the standard name for its argument? F95 draft, 13.14.25 CPU_TIME (TIME) So, only the documentation needs to be changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30950
[Bug libstdc++/28080] header dependencies
--- Comment #19 from paolo at gcc dot gnu dot org 2007-03-03 10:29 --- Subject: Bug 28080 Author: paolo Date: Sat Mar 3 10:29:14 2007 New Revision: 122502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122502 Log: 2007-03-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/bits/stl_algobase.h: Do not include iosfwd, bits/functexcept.h is enough; adjust __copy_aux declarations; remove declaration of copy overload for istreambuf_iterator / ostreambuf_iterator. * src/debug.cc: Include cstdio. * include/ext/rope: Include iosfwd. * include/bits/char_traits.h: Include cstdio and cwchar. * include/bits/stl_algo.h: Remove declaration of find overload for istreambuf_iterator. * include/std/queue: Clean up includes. * include/std/stack: Likewise. * include/std/memory: Likewise. * include/std/algorithm: Likewise. * include/std/vector: Likewise. * include/std/deque: Likewise. * include/std/list: Likewise. * include/bits/stl_tree.h: Likewise. * testsuite/ext/type_traits/remove_unsigned_integer_neg.cc: Adjust dg-error markers. * testsuite/ext/type_traits/add_unsigned_floating_neg.cc: Likewise. * testsuite/ext/type_traits/remove_unsigned_floating_neg.cc: Likewise. * testsuite/ext/type_traits/add_unsigned_integer_neg.cc: Likewise. * testsuite/23_containers/set/operators/1_neg.cc: Likewise. * testsuite/23_containers/map/operators/1_neg.cc: Likewise. * testsuite/20_util/auto_ptr/assign_neg.cc: Likewise. * include/ext/type_traits.h: Fix type of __max_digits10; clean up includes. * testsuite/util/testsuite_hooks.h: Do not include cstddef. * testsuite/util/testsuite_hooks.cc: Do it here. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/char_traits.h trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/ext/type_traits.h trunk/libstdc++-v3/include/std/algorithm trunk/libstdc++-v3/include/std/deque trunk/libstdc++-v3/include/std/list trunk/libstdc++-v3/include/std/memory trunk/libstdc++-v3/include/std/queue trunk/libstdc++-v3/include/std/stack trunk/libstdc++-v3/include/std/vector trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/set/operators/1_neg.cc trunk/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc trunk/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc trunk/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc trunk/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_integer_neg.cc trunk/libstdc++-v3/testsuite/util/testsuite_hooks.cc trunk/libstdc++-v3/testsuite/util/testsuite_hooks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug fortran/30954] intrinsic: DATE_AND_TIME
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-03 10:33 --- Confirmed, but frankly, I believe this could be closed as WONTFIX. It's a missed optimization in a case that probably never happens. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-03 10:33:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30954
[Bug fortran/30964] optional arguments to random_seed
-- 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 |2007-03-03 10:36:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30964
[Bug libfortran/31001] PACK crashes on zero-sized arrays
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-03 10:38 --- Confirmed. I thought I had fixed it, though. Backtrace is (gdb) back #0 pack_internal (ret=0xbfab6628, array=Variable array is not available. ) at /home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/intrinsics/pack_generic.c:162 #1 0x08048c21 in MAIN__ () at pack.f90:18 #2 0x08048d78 in main (argc=Cannot access memory at address 0x4 ) at /home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/fmain.c:18 and I'll give it a look. -- 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 |2007-03-03 10:38:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31001
[Bug fortran/30882] size with initialization expression value for dim= is rejected
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-03 10:43 --- Subject: Bug 30882 Author: burnus Date: Sat Mar 3 10:43:25 2007 New Revision: 122503 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122503 Log: 2007-03-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30882 * check.c (dim_rank_check): The shape of subsections of assumed-size arrays is known. 2007-03-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30882 * gfortran.dg/size_dim.f90: New test. -- Diese und die folgenden Zeilen werden ignoriert -- Mgcc/testsuite/ChangeLog Agcc/testsuite/gfortran.dg/size_dim.f90 Mgcc/fortran/ChangeLog Mgcc/fortran/check.c Added: trunk/gcc/testsuite/gfortran.dg/size_dim.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30882
[Bug fortran/30871] Pointer to substring rejected with Different character lengths in pointer assignment
-- 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 |2007-03-03 10:46:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug c/4076] -Wunused doesn't warn about static function only called by itself.
--- Comment #16 from patchapp at dberlin dot org 2007-03-03 11:50 --- Subject: Bug number PR c/4076 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00171.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
[Bug fortran/24546] [meta-bug] gfortran debugging problems
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-03 12:06
---
Steven Bosscher had made significant progress on this, IIRC. Steven, what's the
status of your patches?
PS: as a minor improvement, we might want to give numeric types a more
Fortran-like name, with a patch such as the following:
Index: trans-types.c
===
--- trans-types.c (revision 122038)
+++ trans-types.c (working copy)
@@ -531,7 +531,7 @@
{
type = gfc_build_int_type (gfc_integer_kinds[index]);
gfc_integer_types[index] = type;
- snprintf (name_buf, sizeof(name_buf), int%d,
+ snprintf (name_buf, sizeof(name_buf), integer(kind=%d),
gfc_integer_kinds[index].kind);
PUSH_TYPE (name_buf, type);
}
@@ -540,7 +540,7 @@
{
type = gfc_build_logical_type (gfc_logical_kinds[index]);
gfc_logical_types[index] = type;
- snprintf (name_buf, sizeof(name_buf), logical%d,
+ snprintf (name_buf, sizeof(name_buf), logical(kind=%d),
gfc_logical_kinds[index].kind);
PUSH_TYPE (name_buf, type);
}
@@ -549,13 +549,13 @@
{
type = gfc_build_real_type (gfc_real_kinds[index]);
gfc_real_types[index] = type;
- snprintf (name_buf, sizeof(name_buf), real%d,
+ snprintf (name_buf, sizeof(name_buf), real(kind=%d),
gfc_real_kinds[index].kind);
PUSH_TYPE (name_buf, type);
type = gfc_build_complex_type (type);
gfc_complex_types[index] = type;
- snprintf (name_buf, sizeof(name_buf), complex%d,
+ snprintf (name_buf, sizeof(name_buf), complex(kind=%d),
gfc_real_kinds[index].kind);
PUSH_TYPE (name_buf, type);
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
||org
Last reconfirmed|2006-01-29 19:54:48 |2007-03-03 12:06:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
[Bug middle-end/31030] New: [Regression 4.3] Segmentation fault of compiled program with -O2
This is with the Polyhedron Fortran Benchmark, http://www.polyhedron.com/pb05/polyhedron_benchmark_suite.html http://www.polyhedron.com/pb05/pb05.zip The test is in ./pb06/lin/source/. gfortran -g -O1 linpk.f90 ./a.out runs without any error. gfortran -g -O2 linpk.f90 ./a.out gives a segmentation fault. Analogously for test_fpu and rnflow. The regression must have happened between 2007-03-02-r122469 and 2007-03-03-r122499. valgrind output for linpk.f90 with -O2 (no error for -O1): ==27168== Invalid read of size 8 ==27168==at 0x400CD2: dscal_ (linpk.f90:424) ==27168==by 0x401C06: dgefa_ (linpk.f90:151) ==27168==by 0x401DC0: MAIN__ (linpk.f90:14) ==27168==by 0x40204D: main (fmain.c:18) ==27168== Address 0x35B7000 is not stack'd, malloc'd or (recently) free'd ==27168== ==27168== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==27168== Access not within mapped region at address 0x35B7000 ==27168==at 0x400CD2: dscal_ (linpk.f90:424) ==27168==by 0x401C06: dgefa_ (linpk.f90:151) ==27168==by 0x401DC0: MAIN__ (linpk.f90:14) ==27168==by 0x40204D: main (fmain.c:18) -- Summary: [Regression 4.3] Segmentation fault of compiled program with -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31030
[Bug fortran/25714] concat of strings create an extra temporary variable
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-03 12:14 --- Created an attachment (id=13136) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13136action=view) Updated version of the patch in comment 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-03 12:36 --- I also get the ICE on i686-linux. We get into compare_cases (resolve.c) and try to compare op1-high and op2-low, but both are functions and not constants, so the values in op1-high-value are meaningless, and comparing them yields random segfaults. If we get it past that point, we later ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:278 (because the expr is not an EXPR_CONSTANT). This will all be fixed when the simplifcation routine for TRANSFER is written. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, jvdelisle at verizon ||dot net Keywords||ice-on-valid-code Known to fail||4.3.0 4.2.0 4.1.2 Last reconfirmed|2007-02-20 13:23:53 |2007-03-03 12:36:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30881
[Bug fortran/30882] [4.1 and 4.2 only] size with initialization expression value for dim= is rejected
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-20 14:04:36 |2007-03-03 13:30:59 date|| Summary|size with initialization|[4.1 and 4.2 only] size with |expression value for dim= is|initialization expression |rejected|value for dim= is rejected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30882
[Bug libfortran/30617] recursive I/O hangs under OSX
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2007-02-05 22:15:24 |2007-03-03 13:31:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/31001] PACK crashes on zero-sized arrays
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-03 14:24
---
Patch below, currently regtesting.
Index: libgfortran/intrinsics/pack_generic.c
===
--- libgfortran/intrinsics/pack_generic.c (revision 122504)
+++ libgfortran/intrinsics/pack_generic.c (working copy)
@@ -93,15 +93,19 @@
index_type count[GFC_MAX_DIMENSIONS];
index_type extent[GFC_MAX_DIMENSIONS];
+ int zero_sized;
index_type n;
index_type dim;
index_type nelem;
dim = GFC_DESCRIPTOR_RANK (array);
+ zero_sized = 0;
for (n = 0; n dim; n++)
{
count[n] = 0;
extent[n] = array-dim[n].ubound + 1 - array-dim[n].lbound;
+ if (extent[n] = 0)
+ zero_sized = 1;
sstride[n] = array-dim[n].stride * size;
mstride[n] = mask-dim[n].stride;
}
@@ -154,6 +158,8 @@
const GFC_LOGICAL_4 *m = mptr;
total = 0;
+ if (zero_sized)
+ m = NULL;
while (m)
{
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
GCC host triplet|i686-pc-linux-gnu |
Keywords||patch, wrong-code
Known to fail||4.1.2 4.2.0 4.3.0
Last reconfirmed|2007-03-03 10:38:13 |2007-03-03 14:24:04
date||
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31001
[Bug libstdc++/31031] New: ostream ambiguous operator
The following program fails to compile (it compiles fine under 4.1.2)
#include iostream
class MyClass {
double x;
public:
MyClass(double X) : x(X) {}
MyClass(int I) : x(I) {}
friend bool operator(int i, const MyClass Z);
};
inline bool operator(int i, const MyClass Z) {
return int(Z.x) == i;
}
int main() {
int k =3;
MyClass X(3.1);
std::cout (k X) std::endl;
}
giving
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20070131/include/g++-v4/ostream: In
destructor 'std::basic_ostream_CharT, _Traits::sentry::~sentry() [with _CharT
= char, _Traits = std::char_traitschar]':
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20070131/include/g++-v4/bits/ostream.tcc:70:
instantiated from 'std::basic_ostream_CharT, _Traits
std::basic_ostream_CharT, _Traits::_M_insert(_ValueT) [with _ValueT = bool,
_CharT = char, _Traits = std::char_traitschar]'
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20070131/include/g++-v4/ostream:201:
instantiated from 'std::basic_ostream_CharT, _Traits
std::basic_ostream_CharT, _Traits::operator(bool) [with _CharT = char,
_Traits = std::char_traitschar]'
g++-4.2_bug.C:19: instantiated from here
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20070131/include/g++-v4/ostream:455:
error: ISO C++ says that these are ambiguous, even though the worst conversion
for the first is better than the worst conversion for the second:
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0-alpha20070131/include/g++-v4/ostream:455:
note: candidate 1: operator(bool, bool) built-in
g++-4.2_bug.C:12: note: candidate 2: bool operator(int, const MyClass)
--
Summary: ostream ambiguous operator
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jarausch at skynet dot be
GCC host triplet: gcc-4.2.0-alpha20070131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/15787] Poor error message with if and blocks
--- Comment #8 from manu at gcc dot gnu dot org 2007-03-03 15:32 --- Subject: Bug 15787 Author: manu Date: Sat Mar 3 15:32:13 2007 New Revision: 122505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122505 Log: 2007-03-03 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c++/15787 * parser.c (struct cp_parser): New IN_IF_STMT. (cp_parser_statement_seq_opt): Handle an unexpected 'else', returning if parsing the body of an 'if' statement or issuing an error and continuing. (cp_parser_selection_statement): Set IN_IF_STMT bit when parsing body of 'if'. (cp_parser_jump_statement): Mask new IN_IF_STMT bit. testsuite/ * g++.dg/parse/else.C: New. * g++.dg/parse/else-2.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/else-2.C trunk/gcc/testsuite/g++.dg/parse/else.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15787
[Bug c++/15787] Poor error message with if and blocks
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-03 15:51 --- Fixed in 4.3.0 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15787
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2007-03-03 15:52 --- Fixed on 4.3 and 4.2. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.2.0 | Known to work|4.3.0 |4.3.0 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug libfortran/31001] PACK crashes on zero-sized arrays
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-03 16:38 --- Subject: Bug 31001 Author: fxcoudert Date: Sat Mar 3 16:37:54 2007 New Revision: 122507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122507 Log: PR libfortran/31001 * intrinsics/pack_generic.c (pack_internal): Add special checks for zero-sized arrays. * gfortran.dg/zero_sized_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_sized_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/pack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31001
[Bug c++/31031] ostream ambiguous operator
--- Comment #1 from pcarlini at suse dot de 2007-03-03 17:23 --- Well, certainly line 455 of ostream didn't change lately and in any case we are implementing literally the condition in 27.6.2.3/4 of the standard. Also, I should add that overloading operator isn't really a best practice (see, for example, C++ Primer, p. 511). Gaby? C++ front-end experts? -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at cs dot tamu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/31031] ostream ambiguous operator
--- Comment #2 from pcarlini at suse dot de 2007-03-03 17:34 --- By the way, avoiding operator would be easy, just change the condition to 2 nested ifs, but I want to be clear about the general issue, whether the library is supposed to be always and everywhere robust wrt overloaded operator and operator||. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/31031] ostream ambiguous operator
--- Comment #3 from pcarlini at suse dot de 2007-03-03 18:09 --- Oh well, a better fix would be inhibit implicit instantiation of the various _M_insert, which we are exporting from the .so library. That is good anyway. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-03 18:09:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/31031] ostream ambiguous operator
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.0 Version|4.2.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-03-03 19:30 --- Subject: Bug 16513 Author: ebotcazou Date: Sat Mar 3 19:29:51 2007 New Revision: 122512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122512 Log: Backport from mainline: 2007-03-01 Peter Breitenlohner [EMAIL PROTECTED] PR other/16513 * Makefile.in: Install library under $(MULTIOSDIR), not $(MULTISUBDIR). Install headers in multilib independent location. Modified: branches/gcc-4_2-branch/libiberty/ChangeLog branches/gcc-4_2-branch/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-03-03 19:31 --- Fixed in the upcoming 4.2.0 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug c++/31031] ostream ambiguous operator
--- Comment #4 from paolo at gcc dot gnu dot org 2007-03-03 19:36 --- Subject: Bug 31031 Author: paolo Date: Sat Mar 3 19:36:20 2007 New Revision: 122513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122513 Log: 2007-03-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31031 * include/bits/istream.tcc: Inhibit implicit instantiation of the _M_insert helpers. * include/bits/ostream.tcc: Likewise for _M_extract. * testsuite/27_io/basic_ostream/inserters_arithmetic/char/ 31031.cc: New. * testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/ 31031.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/31031.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/31031.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/istream.tcc trunk/libstdc++-v3/include/bits/ostream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #8 from doug dot gregor at gmail dot com 2007-03-03 19:50 --- Patch is here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00191.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- Comment #9 from patchapp at dberlin dot org 2007-03-03 19:50 --- Subject: Bug number PR 30666 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00191.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #24 from burnus at gcc dot gnu dot org 2007-03-03 20:55 --- Is this actually now fixed or not? I see a 4.2 and a trunk commit. Can this bug now be closed, is something missing or should it be checked in for 4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #25 from dominiq at lps dot ens dot fr 2007-03-03 21:46 --- Is this actually now fixed or not? No, it is not. The commits are for the side effect of test case intrinsic_actual_2.f90 that has been fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-03 21:47 --- Confirmed, a regression from 4.0.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.0.2 Last reconfirmed|-00-00 00:00:00 |2007-03-03 21:47:29 date|| Summary|ICE with computed goto and |[4.1/4.2/4.3 Regression] ICE |constants |with computed goto and ||constants Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug c++/30988] [4.1/4.2/4.3 Regression] Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-03 21:50 --- Confirmed, a regression from 3.3.3. I made sure in 3.3.3, we would warn about the function if we removed the attribute noreturn so I know the warning works for that case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2007-03-03 21:50:09 date|| Summary|Incorrect no return|[4.1/4.2/4.3 Regression] |statement warning with |Incorrect no return |__attribute__ ((noreturn)) |statement warning with |and __FUNCTION__|__attribute__ ((noreturn)) ||and __FUNCTION__ Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
[Bug c++/26122] [4.0/4.1 regression] Pure specifiers for templates causing trouble
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26122
[Bug libfortran/30690] Clean up m4 files
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-03 22:05 --- Created an attachment (id=13137) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13137action=view) example patch for cshift1 This is how a cleanup could look: Quote everything except for the macros, which need to be unqouted. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30690
[Bug libstdc++/28080] header dependencies
--- Comment #20 from paolo at gcc dot gnu dot org 2007-03-04 00:20 --- Subject: Bug 28080 Author: paolo Date: Sun Mar 4 00:20:26 2007 New Revision: 122518 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122518 Log: 2007-03-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/tr1/functional: Split out hash bits to... * include/tr1/functional_hash.h: ...here. * include/Makefile.am: Add. * include/tr1/unordered_set: Include the latter instead. * include/tr1/unordered_map: Likewise. * include/Makefile.in: Regenerate. * include/tr1/utility (get(std::pair), get(const std::pair)): Mark inline. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_2-branch/libstdc++-v3/include/Makefile.in branches/gcc-4_2-branch/libstdc++-v3/include/tr1/functional branches/gcc-4_2-branch/libstdc++-v3/include/tr1/unordered_map branches/gcc-4_2-branch/libstdc++-v3/include/tr1/unordered_set branches/gcc-4_2-branch/libstdc++-v3/include/tr1/utility -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug libstdc++/28080] header dependencies
--- Comment #21 from paolo at gcc dot gnu dot org 2007-03-04 00:23 --- Subject: Bug 28080 Author: paolo Date: Sun Mar 4 00:23:23 2007 New Revision: 122519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122519 Log: 2007-03-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28080 (partial) * include/tr1/functional: Split out hash bits to... * include/tr1/functional_hash.h: ...here. * include/Makefile.am: Add. * include/tr1/unordered_set: Include the latter instead. * include/tr1/unordered_map: Likewise. * include/Makefile.in: Regenerate. * include/tr1/utility (get(std::pair), get(const std::pair)): Mark inline. Added: branches/gcc-4_2-branch/libstdc++-v3/include/tr1/functional_hash.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug rtl-optimization/30815] [4.3 Regression] pr29965.c fails on the mainline, switches and __builtin_trap
--- Comment #2 from tbm at gcc dot gnu dot org 2007-03-04 01:35 --- I see this on x86_64 and ia64 too. -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc*-*-*| Last reconfirmed|-00-00 00:00:00 |2007-03-04 01:35:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30815
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #7 from tbm at cyrius dot com 2007-03-04 01:42 --- Fails here with 4.3 with: internal compiler error: tree check: expected class 'expression', have 'exceptional' (error_mark) in build_min_nt, at cp/tree.c:1489 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug objc++/31032] New: [4.3 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
The bitfield-1.mm test case fails for me with 4.3 on ia64 with: internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225 -- Summary: [4.3 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug objc++/31032] [4.3 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #1 from tbm at cyrius dot com 2007-03-04 02:05 --- Same on x86_64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug middle-end/30798] mode_dependent_address_p not checked when simplifying subreg
--- Comment #1 from TabonyEE at austin dot rr dot com 2007-03-04 02:25 --- For some reason, defining WORD_REGISTER_OPERATIONS prevents Combine from transforming the HI load followed by the AND with 0xFF into a zero-extending QI load. I don't know why this would be. I think not defining WORD_REGISTER_OPERATIONS should always be safe. I'm sure defining WORD_REGISTER_OPERATIONS is somehow masking the real problem. Another odd thing is that BlackFin (bfin) produces the same code up to Life1, just before Combine, but Combine does not perform the aforementioned transformation even though bfin does not define WORD_REGISTER_OPERATIONS. bfin has a zero-extending QI load pattern and GO_IF_LEGITIMATE_ADDRESS accepts a QI mode POST_INC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30798
[Bug libfortran/31001] [4.1/4.2 only] PACK crashes on zero-sized arrays
-- 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 Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work||4.3.0 Last reconfirmed|2007-03-03 14:24:04 |2007-03-04 07:20:24 date|| Summary|PACK crashes on zero-sized |[4.1/4.2 only] PACK crashes |arrays |on zero-sized arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31001
[Bug c/31033] New: Collect2 will not allow shared gcc with cross compiler
First off, here's what I passed to the gcc configure script: CC=gcc CC=$CC CFLAGS= CXXFLAGS= CPPFLAGS= ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info \ --enable-shared --enable-threads=posix --enable-checking=release \ --with-system-zlib --disable-libunwind-exceptions \ --prefix=/usr --exec-prefix=/usr \ --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc \ --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 \ --libexecdir=/usr/libexec --localstatedir=/var \ --sharedstatedir=/usr/com --mandir=/usr/share/man \ --infodir=/usr/share/info \ --without-long-double-128 \ --enable-languages=c \ --host=x86_64-redhat-linux --build=x86_64-redhat-linux \ --target=powerpc-ibm-aix5.3.0 --with-cpu=default32 \ --with-gnu-as --with-gnu-ld --enable-libssp=no \ --with-sysroot=/usr/powerpc-ibm-aix5.3.0/sys-root If I try to compile hello world on the resultant compiler with the following options, it works (and runs on AIX): [EMAIL PROTECTED] ~]$ powerpc-ibm-aix5.3.0-gcc -c hello.c [EMAIL PROTECTED] ~]$ powerpc-ibm-aix5.3.0-gcc hello.o -o hello [EMAIL PROTECTED] ~]$ ls -l hello -rwxrwxr-x 1 kyle kyle 282114 Mar 3 23:41 hello Howerver, if I try to compile it with a shared libgcc, it fails: [EMAIL PROTECTED] ~]$ powerpc-ibm-aix5.3.0-gcc -c hello.c [EMAIL PROTECTED] ~]$ powerpc-ibm-aix5.3.0-gcc -shared-libgcc hello.o -o hello collect2: init function found in object /usr/lib64/gcc/powerpc-ibm-aix5.3.0/4.1.1/../../../../powerpc-ibm-aix5.3.0/lib/libgcc_s.a I have tracked the error message down to the collect2 program. It comes from collect2.c. Collect2 will run nm on all of the libraries. If it finds a symbol that starts with GLOBAL__FI_, it will report that error, but only if collect2 is built as a cross compiler. This shows that the native gcc in the AIX Toolbox works despite the same export: [EMAIL PROTECTED] ~]$ powerpc-ibm-aix5.3.0-nm /usr/lib64/gcc/powerpc-ibm-aix5.3.0/4.1.1/../../../../powerpc-ibm-aix5.3.0/lib/libgcc_s.a | grep GLOBAL__FI_ 1238 T ._GLOBAL__FI_shr_o 2ae8 d _GLOBAL__FI_shr_o 2ae8 D _GLOBAL__FI_shr_o [EMAIL PROTECTED] ~]$ scp hello.o [EMAIL PROTECTED]: [EMAIL PROTECTED]'s password: hello.o 100% 1040 1.0KB/s 00:00 [EMAIL PROTECTED] ~]$ nm /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.0/libgcc_s.a | grep GLOBAL__FI_ ._GLOBAL__FI_shr_o T 268463976 _GLOBAL__FI_shr_oD 536873824 _GLOBAL__FI_shr_od 536873824 12 [EMAIL PROTECTED] ~]$ gcc -shared-libgcc hello.o -o hello [EMAIL PROTECTED] ~]$ ls -l hello -rwxr-xr-x 1 testuser staff 17487 Mar 03 23:49 hello -- Summary: Collect2 will not allow shared gcc with cross compiler Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kstemen at centeris dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: powerpc-ibm-aix5.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31033
