[Bug ada/27999] FAIL: c64005c
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 08:26 --- Let's assume this is fixed, as per your latest 4.3.0 results -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27999
[Bug ada/29685] testsuite hang running c910002
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 08:28 --- Assuming you haven't disabled this test manually, this is fixed as per your latest test results on 4.3.0 -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29685
[Bug ada/25819] CXF3A01 core dump
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 08:25 --- >From the test results you posted yesterday on 4.3.0, I assume this is fixed: << === acats tests === FAIL: c37215h FAIL: cd10002 FAIL: cxh1001 Native configuration is hppa-unknown-linux-gnu >> -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25819
[Bug fortran/25071] dummy argument larger than actual argument
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-04 08:54 --- Subject: Bug 25071 Author: burnus Date: Fri May 4 07:54:06 2007 New Revision: 124411 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124411 Log: 2007-05-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/25071 * interface.c (compare_actual_formal): Check character length. 2007-05-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/25071 * gfortran.dg/char_length_3.f90: New test. * gfortran.dg/char_result_2.f90: Fix test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
[Bug fortran/25071] dummy argument larger than actual argument
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-04 08:55 --- Note: Only the string length problem is fixed; the array storage extend still needs to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
[Bug fortran/31803] ICE for character pointer => target(range)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-04 08:57 --- Note: Please uncomment also the two marked lines in gcc/testsuite/gfortran.dg/char_result_2.f90 when you fix this PR. http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/char_result_2.f90?r1=124411&r2=124410&pathrev=124411 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE when for character |ICE for character pointer |pointer => target(range)|=> target(range) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31803
[Bug tree-optimization/31797] gcc-4.2.0 racing
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-04 09:05 --- On the mainline I get an ICE: t.c:20: internal compiler error: in compute_antic, at tree-ssa-pre.c:1968 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #96 from jv244 at cam dot ac dot uk 2007-05-04 09:15 --- (In reply to comment #91) > current (i.e. this morning) mainline seems to miscompile CP2K (tested current > CVS of CP2K). Current SVN gfortran compiles CP2K again correctly. Closing the bug again -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31812] New: Better message than "syntax error" when truncating long lines
gfortran silently trunkates lines which gives syntax errors. Especially in free format, the truncation is usually not intended. (In fixed format is sometimes is.) Other compiles print a warning (such as g95, all options; syntax error afterwards), give an error (such as NAG f95) or (silently) accept longer lines (ifort, all options). gfortran prints a warning, but only with -Wall not with -pedantic -std=f95. Real-world example: http://gcc.gnu.org/ml/fortran/2007-05/msg00042.html Message: "," name=",1H",A,1H",">",A,"")',ADVANCE="Yes") blank(1:inden),tag,str(1 1 Error: Syntax error in argument list at (1) -- Summary: Better message than "syntax error" when truncating long lines Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31812
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #41 from pcarlini at suse dot de 2007-05-04 09:41 --- In case it wasn't clear already, many thanks Ian and everyone for fixing this annoying issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31813] New: Warn about deleted feature: H edit descriptor
>From Fortran 95 standard, Annex B, B1: Deleted Features: "H edit descriptor. In FORTRAN 77, and for consistency also in Fortran 90, there was an alternative form of character string edit descriptor, which had been the only such form in FORTRAN 66; this has been deleted." Other compiles warn: NAG: f95 Deleted feature used: H edit descriptor Intel: ifort -stand f95 Warning: The cH edit descriptor has been deleted in Fortran 95. g95 -std=f95 Warning (100): The H format specifier is a deleted language feature in format string at (1) Example: SUBROUTINE ERROR_SUB(TAG,STR,BLANK) IMPLICIT none CHARACTER (LEN=*) :: TAG CHARACTER (LEN=*) :: STR CHARACTER (LEN=*) :: BLANK INTEGER inden, uixml, i i=LEN_TRIM(str) inden = 10 WRITE(uixml,'(A,"",A,"")',ADVANCE="Yes") blank(1:inden),tag,str(1:i) END SUBROUTINE ERROR_SUB -- Summary: Warn about deleted feature: H edit descriptor Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31813
[Bug ada/26465] Ada.Characters.Conversions comment announces Ada.Characters.Handling
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-04 09:58 --- Was fixed on 2006-10-31 -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26465
[Bug ada/30686] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 10:08 --- Fixed in 4.3.0 -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30686
[Bug ada/29157] gnattools fail on cross compilation - Makefile bug?
--- Comment #5 from charlet at gcc dot gnu dot org 2007-05-04 10:13 --- install.texi would be the place to add this documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29157
[Bug fortran/31781] fortran regressions on trunk if you --disable-checking
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:26 --- Subject: Bug 31781 Author: fxcoudert Date: Fri May 4 09:26:41 2007 New Revision: 124412 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124412 Log: PR fortran/31781 * simplify.c (gfc_simplify_repeat): Don't put function call with side effect in a gcc_assert(). Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31781
[Bug fortran/31781] fortran regressions on trunk if you --disable-checking
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:29 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31781
[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-04 10:33 --- Confirmed. Should be easy to work around. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-04 10:33:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31809
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:44 --- (In reply to comment #10) > Again, I am unable to really test this, but here is a suggestion This patch fixes the ICE, and I agree it's the right thing to do. I retested your other patch from scratch (the one to decl.c) and it doesn't fix the double-error problem. Maybe your forgot some part of it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug ada/24564] Bug box in Ada compiler: in create_tmp_var, at gimplify.c:368
--- Comment #6 from charlet at gcc dot gnu dot org 2007-05-04 10:55 --- Fixed on trunk -- charlet 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=24564
[Bug ada/24381] Error in visibility rules of formal generic packages
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-04 11:22 --- Compiles cleanly on trunk -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24381
[Bug ada/22251] Bug box in Ada compiler: Assert_Failure sinfo.adb:2479, Error detected at test.adb:12:16
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-04 11:31 --- Now compiles properly (and generates error message as expected). Arno -- charlet 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=22251
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #42 from rguenth at gcc dot gnu dot org 2007-05-04 11:45
---
I put it on the tester. A testcase that does regress (simplified from
tramp3d):
template
class Vector
{
public:
Vector()
{
for (int i = 0; i < D; ++i)
new (&x_m[i]) T();
}
T& operator[](int i) { return x_m[i]; }
private:
T x_m[D];
};
void foo(Vector *m)
{
Vector v;
v[0] = 1.0;
v[1] = 2.0;
v[3] = 3.0;
*m = v;
}
where we can no longer optimize the redundant stores to v:
:
v.x_m[0] = 0.0;
__asm__ __volatile__("":"=m" v.x_m[0]:"m" v.x_m[0]);
v.x_m[1] = 0.0;
__asm__ __volatile__("":"=m" v.x_m[1]:"m" v.x_m[1]);
v.x_m[2] = 0.0;
__asm__ __volatile__("":"=m" v.x_m[2]:"m" v.x_m[2]);
v.x_m[0] = 1.0e+0;
v.x_m[1] = 2.0e+0;
v.x_m[3] = 3.0e+0;
*m = v;
return;
vs.
:
v.x_m[2] = 0.0;
v.x_m[0] = 1.0e+0;
v.x_m[1] = 2.0e+0;
v.x_m[3] = 3.0e+0;
*m = v;
return;
and assembly:
_Z3fooP6VectorIdLi3EE:
.LFB17:
xorl%r9d, %r9d
movq%r9, -40(%rsp)
movq%r9, -32(%rsp)
movq%r9, -24(%rsp)
movabsq $4607182418800017408, %r8
movabsq $4611686018427387904, %rsi
movq-24(%rsp), %rax
movq%r8, -40(%rsp)
movq%rsi, -32(%rsp)
movq-40(%rsp), %rcx
movq-32(%rsp), %rdx
movq%rax, 16(%rdi)
movq%rcx, (%rdi)
movq%rdx, 8(%rdi)
ret
vs.
_Z3fooP6VectorIdLi3EE:
.LFB17:
movabsq $4607182418800017408, %r8
movabsq $4611686018427387904, %rsi
movq$0, -24(%rsp)
movq%r8, -40(%rsp)
movq%rsi, -32(%rsp)
movq-40(%rsp), %rcx
movq-32(%rsp), %rdx
movq-24(%rsp), %rax
movq%rcx, (%rdi)
movq%rdx, 8(%rdi)
movq%rax, 16(%rdi)
ret
this happens in hot tramp3d loops and is a quite common idiom for initializing
storage. To fix this we need to avoid creating the asm if the type of the
original storage is the same as the other.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/31804] gcc segfaults on very long pointer chains
--- Comment #4 from joseph at codesourcery dot com 2007-05-04 12:00 --- Subject: Re: gcc segfaults on very long pointer chains On Fri, 4 May 2007, bangerth at dealii dot org wrote: > But seriously, while I do think that we should strive to compile even > programs that are "weird" or "unusual" in their requirements on the > compiler, I think that this one goes a little overboard. I would, > however, be interested to hear how many levels of pointers gcc > actually *can* compile. I would imagine it's at least a few > hundred, maybe thousand. Maybe you could try to figure out? That would depend on your stack limit (so the question would really be, for each extra MB of stack limit how many more levels can it compile)? For such extreme programs I think it's reasonable to expect users to increase their stack limit when running the compiler. Although in this case, it would be reasonably straightforward to make c_parser_declarator iterative (with an internal linked list on the parser obstack) rather than recursive - if that were actually of use in compiling real code with real stack limits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31804
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #43 from pcarlini at suse dot de 2007-05-04 12:03 --- (In reply to comment #42) > this happens in hot tramp3d loops and is a quite common idiom for initializing > storage. To fix this we need to avoid creating the asm if the type of the > original storage is the same as the other. Many thanks Richard. Indeed, I find this already mentioned optimization a very sensible thing to add. (By the way, someone should tell the tramp3d developers that using placement new for a POD type like double isn't a very smart idea ;) The only tricky point for default inizialization is whether using memset or a plain loop) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #44 from pcarlini at suse dot de 2007-05-04 12:07 --- (In reply to comment #43) > (By the way, someone should tell the tramp3d developers that using placement > new for a POD type like double isn't a very smart idea ;) The only tricky > point > for default inizialization is whether using memset or a plain loop) Forgot to add a detail that may be of interest, however: C++03 *fails* to classify as POD some very common and simple types which are morally PODs: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html Thus let's not assume users to be too good here: sometimes, in generic code, they may end-up calling placement new also for very simple types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:10 --- Subject: Bug 31251 Author: fxcoudert Date: Fri May 4 11:10:06 2007 New Revision: 124415 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124415 Log: PR fortran/31251 * simplify.c (gfc_simplify_len): Only simplify integer lengths. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:31 --- RESHAPE is not simplified, because "x" has type EXPR_CONSTANT (scalar constant) which is not accepted by the simplification routine gfc_simplify_reshape, because it wants arguments to be EXPR_ARRAY (ie array constructor). Thus, the following code fails to compile: integer, parameter :: x(1) = 1, y(1) = reshape(x,(/1/)) print *, y end while that other one works fine: integer, parameter :: x(1) = (/1/), y(1) = reshape(x,(/1/)) print *, y end I don't know if it's OK for x to have type EXPR_CONSTANT, but I think it is. In that case, gfc_simplify_reshape should be modified to account for this possibility. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-03-17 15:42:32 |2007-05-04 12:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug fortran/31764] NEW_LINE with array argument
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:52
---
(Side note: NEW_LINE is not an elemental function. It can be used with an array
argument, but it's different from being elemental.)
As for the bug itself, there's no reason that the argument to NEW_LINE should
be constant: the only requirement is that it's of character kind (all that is
used in NEW_LINE is the character kind, which is always known at compile-time).
So, the following patch fixes it, and I believe it does the right thing:
Index: simplify.c
===
--- simplify.c (revision 124415)
+++ simplify.c (working copy)
@@ -2641,13 +2641,8 @@ gfc_simplify_new_line (gfc_expr *e)
{
gfc_expr *result;
- if (e->expr_type != EXPR_CONSTANT)
-return NULL;
-
result = gfc_constant_result (BT_CHARACTER, e->ts.kind, &e->where);
-
result->value.character.string = gfc_getmem (2);
-
result->value.character.length = 1;
result->value.character.string[0] = '\n';
result->value.character.string[1] = '\0'; /* For debugger */
This patch is donated to whomever has time to confirm that it does what it
should, that it conforms to the standard and that it regtests. (I'll take care
of it next week if noone has time before then.) The following testcase now
passes:
$ cat a.f90
character(len=10) :: a1
character(len=10) :: a2(2)
character(len=10), parameter :: a3 = "1234567890"
character(len=10), parameter :: a4(2) = "1234567890"
character(len=10), parameter :: a5(2) = repeat("1234567890",2)
print *, ichar(new_line(a1))
print *, ichar(new_line(a2))
print *, ichar(new_line(a3))
print *, ichar(new_line(a4))
print *, ichar(new_line(a5))
end
$ gfortran a.f90 && ./a.out
10
10
10
10
10
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
Keywords||patch
Known to fail||4.3.0
Last reconfirmed|2007-04-30 15:43:12 |2007-05-04 12:52:17
date||
Summary|[f2003] ice in new_line if |NEW_LINE with array argument
|used as elemental function |
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31764
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #45 from rguenth at gcc dot gnu dot org 2007-05-04 13:03 --- Of course in the tramp3d case the code is written in such a generic way that it supports non-POD data members... (And yes, "upstream" has this optimized, but tramp3d-v4.cpp is about having a gcc testcase, not perfectly user-written code ;)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31674] [4.3 Regression] internal consistency failure on ia64 with -O
--- Comment #7 from tbm at cyrius dot com 2007-05-04 13:17 --- Alexandre, can you investigate this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
[Bug ada/19002] GNAT BUG DETECTED, unqualified record aggregate triggers
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 13:26 --- gcc -c matter.ads no longer crashes the compiler -- charlet 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=19002
[Bug ada/18876] Bug box, Assert_Failure at namet.adb:630, on legal program
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 13:42 --- Compiles cleanly on trunk -- charlet 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=18876
[Bug ada/18845] Illegal program not detected, RM 4.7(3)
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 13:44 --- Fixed on trunk: $ gcc -c test_134.adb test_134.adb:11:24: expected type "T1" defined at line 3 test_134.adb:11:24: found type "T1'Class" defined at line 3 test_134.adb:13:17: expected type "T1" defined at line 3 test_134.adb:13:17: found type "T1'Class" defined at line 3 -- charlet 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=18845
[Bug ada/17960] GNAT.Sockets Stream feature not working properly
--- Comment #5 from charlet at gcc dot gnu dot org 2007-05-04 14:29 --- Closing, since it's not clear what behavior the reporter is expecting. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17960
[Bug c++/31816] New: If a function foo is defined before declaring a template class A, overloaded version of foo defined after the class declaration will not be available within class A.
Let us consider the following code:
-
void qHash(double) {}
template
struct QSet
{
void foo()
{
qHash(T());
}
};
// void qHash(double) {} // ok if placed here
void qHash(int*) {}
int main()
{
QSet s;
s.foo(); // ok
QSet sp;
sp.foo(); // do not compile, qHash(int*) is not considered.
}
-
It does not compile, because the overloaded version of qHash() for
int* is not available in QSet, even if QSet is instantiated after the
declaration of qHash(int*). If no qHash function is defined before the
declaration of QSet, it works fine. Although I'm not absolutely
certain that this code is valid, my intuition tells me this behavior
is strongly suspect ..
It works fine with g++ 4.0.4, 3.3 and 2.95.
Environment:
System: Linux stageuei9 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686
GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
How-To-Repeat:
Compile the given code.
--- Comment #1 from nicolas dot burrus at ensta dot fr 2007-05-04 14:31
---
Fix:
Do not overload a function before and after a template class
using it.
--
Summary: If a function foo is defined before declaring a template
class A, overloaded version of foo defined after the
class declaration will not be available within class
A.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolas dot burrus at ensta dot fr
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31816
[Bug fortran/31251] Non-integer character length leads to segfault
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-05-04 14:36 --- I noticed after applying the patch to simplify.c the double error problem returned. I will continue on that part. Subtle things going on here. Side effects. At least we have the segfault resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31803] ICE for character pointer => target(range)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-04 14:40 --- Subject: Bug 31803 Author: burnus Date: Fri May 4 13:40:32 2007 New Revision: 124419 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124419 Log: 2007-05-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/31803 * expr.c (gfc_check_pointer_assign): Check for NULL pointer. 2007-05-04 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/31803 * gfortran.dg/char_pointer_assign_3.f90: New test. * gfortran.dg/char_result_2.f90: Re-enable test. Added: trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31803
[Bug fortran/31803] ICE for character pointer => target(range)
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-04 14:46 --- Fixed in 4.3. Not for 4.2.0. If someone has strong feelings about 4.2.1, please reopen. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.0 4.2.0 4.1.2 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31803
[Bug ada/16101] Illegal program not detected, pragma Convention after freeze
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 14:50 --- Fixed on trunk: $ gcc -c test_248687.ads test_248687.ads:6:04: representation item appears too late -- charlet 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=16101
[Bug fortran/31210] I/O of string with (non-constant) zero length
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 15:06
---
Reduced testcase:
integer :: l = 0
write(*,'(A,I1)') foo(), 0
contains
function foo()
character(len=l) :: foo
foo = ""
end function
end
When a function result is a string of length 0, and that length is not known at
compile time, we create it with _gfortran_internal_malloc(0), which returns
NULL. The library is gets confused when seeing that NULL pointer, even though
the length is also passed and is zero, and requests more data elements (thus
munching the next integer in the I/O list).
If it's deemed that this is a library problem, as I think, I propose the
following patch (which fixes both the original and the reduced testcases, and
regtests fine on i686-linux):
Index: libgfortran/io/transfer.c
===
--- libgfortran/io/transfer.c (revision 124285)
+++ libgfortran/io/transfer.c (working copy)
@@ -1401,8 +1401,17 @@ transfer_logical (st_parameter_dt *dtp,
void
transfer_character (st_parameter_dt *dtp, void *p, int len)
{
+ static char *empty_string[0];
+
if ((dtp->common.flags & IOPARM_LIBRETURN_MASK) != IOPARM_LIBRETURN_OK)
return;
+
+ /* Strings of zero length can have p == NULL, which confuses the
+ transfer routines into thinking we need more data elements. To avoid
+ this, we give them a nice pointer. */
+ if (len == 0 && p == NULL)
+p = empty_string;
+
/* Currently we support only 1 byte chars, and the library is a bit
confused of character kind vs. length, so we kludge it by setting
kind = length. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org, fxcoudert at gcc dot
||gnu dot org
Keywords||patch
Known to fail||4.1.3 4.2.0 4.3.0
Last reconfirmed|2007-03-21 17:05:21 |2007-05-04 15:06:10
date||
Summary|wrong code generated: |I/O of string with (non-
|character MERGE(...) with |constant) zero length
|MASK=.false.|
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #46 from rguenth at gcc dot gnu dot org 2007-05-04 15:31 --- http://www.suse.de/~gcctest/c++bench/tramp3d/ 2nd graph from the top :( boost ICEs: /gcc/spec/sb-vangelis-head-64/boost_1_33_1/boost/wave/util/unput_queue_iterator.hpp:221: warning: suggest parentheses around && within || ../cpp.cpp: In member function 'typename boost::spirit::parser_result, ScannerT>::type boost::spirit::sequence::parse(const ScannerT&) const [with ScannerT = boost::spirit::scanner, boost::spirit::match_policy, boost::spirit::action_policy> >, A = boost::spirit::sequence >, boost::spirit::ref_value_actor >, boost::spirit::action, boost::spirit::ref_value_actor > >, B = boost::spirit::action, boost::spirit::ref_value_actor >]': ../cpp.cpp:715: internal compiler error: in get_indirect_ref_operands, at tree-ssa-operands.c:1704 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. the run is not yet finished (currently mico is running). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31210] I/O of string with (non-constant) zero length
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-04 16:04 --- I agree, this patch is OK for trunk Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'
--- Comment #9 from eweddington at cso dot atmel dot com 2007-05-04 16:06 --- >From Bjoern Haase: Hi all, I think that we could resolve this ICE by adding an unnamed pattern like (define_insn "*strangeMovhi" [(set (mem:HI (plus:HI (reg:HI 28) (const_int 1))) (match_operand:HI 0 "general_operand" "r"))] "" "st %A0,y+1 \n\t st %B0,y+2" [(set_attr "length" "2")]) to the machine description "avr.md" . That might cure the symptoms and does not resolve the underlying problem with reload, but this might be a fix for the immediate issue. Note that above remark is untested pseudo-code. Yours, Bjoern. P.S.: Eric, you might add this remark to the bugzilla entry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
[Bug fortran/31210] I/O of string with (non-constant) zero length
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:14 --- Subject: Bug 31210 Author: fxcoudert Date: Fri May 4 15:14:07 2007 New Revision: 124428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124428 Log: PR libfortran/31210 * io/transfer.c (transfer_character): Avoid passing a NULL pointer as source to the transfer routines, if the string length is zero. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug fortran/31210] I/O of string with (non-constant) zero length
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:20 --- Subject: Bug 31210 Author: fxcoudert Date: Fri May 4 15:20:17 2007 New Revision: 124429 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124429 Log: PR libfortran/31210 * gfortran.dg/zero_length_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_length_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug libfortran/31210] I/O of string with (non-constant) zero length
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:21 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|fortran |libfortran Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
[Bug fortran/29523] [4.1/4.2 only] ICE with some non up-to date .mod files
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:38 --- I can reproduce that ICE with 4.2.0. It's working fine with gfortran 4.3 (even under ElectricFence and valgrind). It's not a regression from the 4.1 branch, since you already had that problem there, as far as I understand. It has small impact (if you add dependencies to your makefile, it won't happen, right?) so it will not be fixed. Thanks for reporting, and I hope this bad news for you won't put you off reporting other bugs in the future! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Keywords||ice-on-invalid-code Known to fail||4.1.3 4.2.0 Known to work||4.3.0 Resolution||WONTFIX Summary|ICE with some non up-to date|[4.1/4.2 only] ICE with some |.mod files |non up-to date .mod files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29523
[Bug fortran/31467] internal compiler error when compiling with gfortran
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:40 --- Closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Known to fail||4.2.0 Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31467
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:49 --- Also happens on i686-linux. It's a 4.1/4.2 regression, which means we could theoretically try to fix it. I'm closing this as WONTFIX nonetheless due to the small impact of the bug (it's triggered by invalid code) and the fact that we have already much on our plates. If someone wants to take care of it, of if you (Terry) want to provide a patch, it will be welcome! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |RESOLVED GCC host triplet|x86_64-unknown-linux-gnu| Keywords||ice-on-invalid-code Known to fail|4.1.2 4.2.0 |4.1.0 4.1.2 4.2.0 Known to work|4.3.0 |4.3.0 4.0.4 Resolution||WONTFIX Summary|ICE for module function |[4.1/4.2 only] ICE for |returning automatic array |module function returning ||automatic array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #47 from ian at airs dot com 2007-05-04 16:54 --- Unfortunately there is no obvious way to avoid creating the asm if the types are the same. The reason is that the dynamic types are different, and we don't know the dynamic type. Look at your original test case: Bar *b = new (f) Bar; b->p = 0; f = new (f) Foo; Here f has type Foo*. So if we test whether the types are the same, we conclude that we don't need any blockage in the last statement quoted above. But that misses the fact that although the static type of *f is Foo, the dynamic type of *f is Bar. Any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #48 from rguenth at gcc dot gnu dot org 2007-05-04 16:57 --- Doh, you are right. So we're back to doing it in the aliasing machinery and with a new tree-code I think. On IRC Danny said he "can do it" ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-04 17:20 --- Segafult is because sym->ts.cl is NULL coming into gfc_conv_function_call. I suspect reshape is not getting resolved correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31817] New: Give at least a warning for specification function without explicit interface
"A function is a specification function if it is a pure function, is not a standard intrinsic function, is not an internal function, is not a statement function, and does not have a dummy procedure argument." This is true for "fn" in: function f2 (fn, i) integer :: i, fn character (len = fn (i)) :: f2 Other compilers give an error as "fn" has no explicit interface (with "PURE"). gfortran simply accepts this statement function. It should at least spit out a warning. $ ifort gfortran.dg/char_result_7.f90 fortcom: Error: gfortran.dg/char_result_7.f90, line 36: An explicit interface is required for a specification function. [FN] $ NAG f95 gfortran.dg/char_result_7.f90 Error: gfortran.dg/char_result_7.f90, line 36: Reference to non-specification function FN in specification expression $ g95 gfortran.dg/char_result_7.f90 [...] Error: Specification function 'fn' at (1) must be PURE -- Summary: Give at least a warning for specification function without explicit interface Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31817
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 17:29 --- (In reply to comment #5) > Segafult is because sym->ts.cl is NULL coming into gfc_conv_function_call. I > suspect reshape is not getting resolved correctly. I've given this one a look this afternoon, and I couldn't see where the problem is when resolving reshape. It is in fact more general, since TRANSPOSE also has this issue, and I think other transformational intrinsics would behave the same: type data character(len=1) :: a end type type(data), target :: z(1,1) z(:,:)%a = "1" write(*,*) transpose(z(:,:)%a(:)) write(*,*) transpose(z(:,:)%a(1:1)) end That being said, I don't have the slightest idea where the charlen should be set. (In the above code, the first TRANSPOSE line works fine: where is that charlen set?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #3 from terry at chem dot gu dot se 2007-05-04 17:46 --- While being a reasonably uncommon case, AFAICT it's a legal construct. That is: not invalid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #4 from terry at chem dot gu dot se 2007-05-04 17:50 --- (I guess I should qualify that. I don't have a copy of the standard laying around to check, but it's legal according to the Ellis, Philips and Lahey book.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-04 17:51 --- The problem is transpose related. In gfc_conv_intrinsic_funcall we pull in the symbol with gfc_get_symbol_for_expr and then do nothing with it before calling gfc_conv_function_call. The symbol type is BT_UNKNOWN and the name is _gfortran_transpose_char. cl is not set, so at this point I think we look at where that symbol is first generated in simplyfy.c or intrinsic.c. I will have to grep for it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31818] New: Wrongly accepts namelists with assumed-sized arrays
subroutine test(cha) implicit none character(len=10) :: cha(:) namelist /z/ cha end subroutine test See also: gfortran.dg/namelist_14.f90 This is invalid: "5.4 NAMELIST statement" "C574 (R553) A namelist-group-object shall not be an assumed-size array." Other compilers reject this: ifort: A NAMELIST group object must not be an array with nonconstant bounds. [CHA] g95: Variable 'cha' at (1) must have an explicit shape to be in a NAMELIST NAG f95: Namelist-group-object CHA is an array dummy with non-constant bounds -- Summary: Wrongly accepts namelists with assumed-sized arrays Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31818
[Bug fortran/31820] New: Warning if case label value exceeds maximum value for type
integer(kind=1) i ! kind = 1, -128 <= i < 127 select case (i) case (200) ! kind = 4, unreachable because of range of i Taken from gfortran.dg/select_5.f90. This is valid, but one should print a warning. One may also print an error since having such a case label does not make sense. NAG f95: warning: case label value exceeds maximum value for type g95: Error: Integer overflow in CASE statement at (1) ifort: Error: select_5.f90, line 11: The case-value is out-of-range. -- Summary: Warning if case label value exceeds maximum value for type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #5 from kargl at gcc dot gnu dot org 2007-05-04 18:14 --- (In reply to comment #4) > (I guess I should qualify that. I don't have a copy of the standard laying > around to check, but it's legal according to the Ellis, Philips and Lahey > book.) > It is not valid code. The variable i is being used without it being set to some value, ie., i is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #6 from terry at chem dot gu dot se 2007-05-04 18:35 --- Created an attachment (id=13507) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13507&action=view) Revised acmod.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #7 from terry at chem dot gu dot se 2007-05-04 18:35 --- Created an attachment (id=13508) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13508&action=view) Revised nnh.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug fortran/31720] [4.1/4.2 only] ICE for module function returning automatic array
--- Comment #8 from terry at chem dot gu dot se 2007-05-04 18:37 --- (In reply to comment #5) > (In reply to comment #4) > > (I guess I should qualify that. I don't have a copy of the standard laying > > around to check, but it's legal according to the Ellis, Philips and Lahey > > book.) > > > > It is not valid code. The variable i is being used without it being set > to some value, ie., i is undefined. Well, obviously. Also obviously in the code in which I discovered the bug the dimensioning variable was set. Attached are revised codes that are 100% legal, give no warnings or errors with either g95 or ifort, pass Lahey's online standards conformance test and still produce the ICE with gfortran 4.2. Interestingly, if i is defined in nnh.f90 before the call to f the ICE goes away. Thus, while it may not effect the WONTFIX, I'm changing the keyword to ice-on-valid-code. (OK, that's the end of my "I know Fortran!" rant! ;-) -- terry at chem dot gu dot se changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
[Bug target/22539] Internal compiler error with maximum sized array
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-04 19:02 --- Subject: Bug 22539 Author: dfranke Date: Fri May 4 18:02:18 2007 New Revision: 124437 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124437 Log: gcc/fortran: 2007-05-04 Daniel Franke <[EMAIL PROTECTED]> PR fortran/22539 * intrinsic.c (add_subroutines): Added FSEEK. * intrinsic.h (gfc_resolve_fseek_sub, gfc_check_fseek_sub): New. * iresolve.c (gfc_resolve_fseek_sub): New. * check.c (gfc_check_fseek_sub): New. * intrinsic.texi (FSEEK): Updated. gcc/testsuite: 2007-05-01 Daniel Franke <[EMAIL PROTECTED]> PR fortran/22539 * gfortran.dg/fseek.f90: New test. libgfortran: 2007-05-04 Daniel Franke <[EMAIL PROTECTED]> PR fortran/22539 * io/intrinsics.c (fseek_sub): New. * io/unix.c (fd_fseek): Change logical and physical offsets only if seek succeeds. * gfortran.map (fseek_sub): New. Added: trunk/gcc/testsuite/gfortran.dg/fseek.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/io/intrinsics.c trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22539
[Bug fortran/22359] [4.1/4.2 regression] fseek intrinsic not implemented
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-04 19:34 --- Fixed in trunk. Due to a typo in the PR number, the commit message went to PR22539. Sorry for that :( As it is a regression wrt g77, this patch probably needs to be backported to 4.1/4.2. Unassigning myself for now. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work||4.3.0 Summary|fseek intrinsic appears to |[4.1/4.2 regression] fseek |be unimplemented|intrinsic not implemented Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22359
[Bug fortran/22359] fseek intrinsic not implemented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] fseek |fseek intrinsic not |intrinsic not implemented |implemented Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22359
[Bug libgcj/31659] config-int.h:327:1: error: "INT8_MIN" redefined
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-05-04 19:58 --- The same happens on Solaris up to and including release 9. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-04 19:58:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31659
[Bug fortran/31821] New: character pointer => target(range) should detect if lengths don't match
character (len=4), s1 character (len=20), pointer :: p1 s1 = 'abcd' p1 => s1(2:3) should be rejected at compile time as len(s1(2:3)) == 2 but p1 has the length 20. This is not detected because primary.c's match_varspec contains: if (substring) primary->ts.cl = NULL; If one removes this check, the proper error: Error: Different character lengths in pointer assignment at (1) is shown. The solution is to resolve ts.cl->length for substrings if possible and only set it to NULL if it is not known at compile time. -- Summary: character pointer => target(range) should detect if lengths don't match Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
[Bug fortran/31822] New: Missing run-time bound checks for character pointer => target
Test case. The comments show what NAG f95 -C=all prints at run time. program ptr implicit none character(len=10), target :: s1 character(len=5), pointer :: p1 integer, volatile :: i i = 8 ! Unequal character lengths (5 and 8) in pointer assignment p1 => s1(1:i) call bar(s1) contains subroutine bar(s) character(len=*),target :: s character(len=17),pointer :: p ! Unequal character lengths (17 and 10) in pointer assignment p => s end subroutine bar end program ptr -- Summary: Missing run-time bound checks for character pointer => target Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug libgomp/28482] Cannot use libgomp in shared library
--- Comment #3 from jakub at gcc dot gnu dot org 2007-05-04 20:21 --- Subject: Bug 28482 Author: jakub Date: Fri May 4 19:21:18 2007 New Revision: 124445 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124445 Log: PR libgomp/28482 * configure.tgt: Don't link with -Wl,-z,nodlopen even on Linux. Modified: trunk/libgomp/ChangeLog trunk/libgomp/configure.tgt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28482
[Bug libfortran/31760] missing elemental applicability
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-04 20:24 --- Subject: Bug 31760 Author: dfranke Date: Fri May 4 19:24:43 2007 New Revision: 124446 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124446 Log: gcc/fortran: 2007-05-04 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31760 * intrinsic.c (add_functions): Replaced calls to gfc_check_g77_math1 by gfc_check_fn_r to avoid checks for scalarity. * check.c (gfc_check_besn): Removed check for scalarity. (gfc_check_g77_math1): Removed. * intrinsic.h (gfc_check_g77_math1): Removed. gcc/testsuite: 2007-05-04 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31760 * gfortran.dg/erf.f90: New test. * gfortran.dg/besxy.f90: New test. [gcc/fortran/ChangeLog was already committed in r124441 by accident] Added: trunk/gcc/testsuite/gfortran.dg/besxy.f90 trunk/gcc/testsuite/gfortran.dg/erf.f90 Modified: trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
[Bug libfortran/31760] missing elemental applicability
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-04 20:29 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.1.2 4.2.0 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-04 20:39 --- I have been chasing this around a bit, clear into decl.c and matchexp.c Nowhere does cl get set. I wonder if there is a separate code path taken when A is defined as a component of a derived type. Stating the obvious, we are missing something here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-04 20:43 --- This looks suspiciously like the problem we are hunting down in pr31197. Can you have a look and see if its related, if not the same bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
[Bug fortran/31627] -bounds-check doesn't check lower bound of assumed-sized array
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-04 21:32 --- Created an attachment (id=13509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13509&action=view) Tentative patch for this bug Not yet fully tested, nor regtested, but it should do the deed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31627
[Bug libgcj/31659] config-int.h:327:1: error: "INT8_MIN" redefined
--- Comment #7 from andreast at gcc dot gnu dot org 2007-05-04 22:06 --- builds here too: sparc-sun-solaris2.8, multilib, native 32-bit. Tests are failing due to boehm-gc stuff: sp out of bounds and compilation complains about: /export/data/devel-test/gcc-svn/trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Messages.java:64: warning: visibility attribute not supported in this configuration; ignored -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31659
[Bug fortran/31823] New: [4.2 regression] COMPLEX not documented
The COMPLEX intrinsic is not documented in 4.2. -- Summary: [4.2 regression] COMPLEX not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-04 22:11 --- Created an attachment (id=13510) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13510&action=view) Documentation patch for COMPLEX -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31821] character pointer => target(range) should detect if lengths don't match
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-04 22:14 --- See also: http://gcc.gnu.org/ml/fortran/2007-05/msg00072.html One also needs a run-time test for: character (len=4), target :: s1 character (len=2), pointer :: p1 s1 = 'abcd' p1 => s1(1:2) if(s1 /= 'abcd') call abort() if(p1 /= 'ab') call abort() end There might be already such a check, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
[Bug fortran/31725] substring bound evaluated multiple times: wrong code for string(function():) = 'X'
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 22:15
---
Here's a patch that avoids multiple evaluation of substring start and end
indices. It was tested on the testcase, also by changing the (start:) range
into a (:end) range, and also by using -fbounds-check (which evaluated the
start and end indices a few other times). It's not fully regtested yet, though.
Index: trans-expr.c
===
--- trans-expr.c(revision 124285)
+++ trans-expr.c(working copy)
@@ -261,6 +261,9 @@ gfc_conv_substring (gfc_se * se, gfc_ref
gfc_conv_string_parameter (se);
else
{
+ /* Avoid multiple evaluation of substring start. */
+ start.expr = gfc_evaluate_now (start.expr, &se->pre);
+
/* Change the start of the string. */
if (TYPE_STRING_FLAG (TREE_TYPE (se->expr)))
tmp = se->expr;
@@ -279,6 +282,8 @@ gfc_conv_substring (gfc_se * se, gfc_ref
gfc_conv_expr_type (&end, ref->u.ss.end, gfc_charlen_type_node);
gfc_add_block_to_block (&se->pre, &end.pre);
}
+ end.expr = gfc_evaluate_now (end.expr, &se->pre);
+
if (flag_bounds_check)
{
tree nonempty = fold_build2 (LE_EXPR, boolean_type_node,
--
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
Keywords||patch
Last reconfirmed|2007-04-27 18:59:17 |2007-05-04 22:15:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug ada/31824] New: Code generation problem with gnat-4.1.2
I've realized a strange code generation behavior I cannot explain and I think to be a bug. It's merely about that a function calls to another one with a parameter read from a constant array. The constant array superfluously gets copied onto the stack. I've attached the test code with one can reproduce the problem. Compile it with command: gnatmake -c -s bug.adb (copying "manually" byte for byte) gnatmake -c -Os -s bug.adb (copying by calling to memcpy) with objdump -D bug.o you can check the result. -- Summary: Code generation problem with gnat-4.1.2 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: theorizer at freemail dot hu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31824
[Bug ada/31824] Code generation problem with gnat-4.1.2
--- Comment #1 from theorizer at freemail dot hu 2007-05-04 22:20 --- Created an attachment (id=13511) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13511&action=view) the code snippet for reproducing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31824
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #9 from burnus at gcc dot gnu dot org 2007-05-04 22:29 --- If ts.cl->length is set to one, the test case of comment 6 works; see also http://gcc.gnu.org/ml/fortran/2007-05/msg00072.html which contains a bogus patch which fixes this. As that patch messes around with length, the test case of comment 0 fails. (The "res" variable contains "1" instead of "22", i.e. the value of a(1:1) instead of a(2:2) is used.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug c++/31825] New: bug in g++ a.out for stl::map
# gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ./configure
Thread model: posix
gcc version 3.4.4
I have compiled a simple test program in C++ using stl::map.
#g++ -DDOESNT_WORK test.cpp
#./a.out
Added value
TYpe=0name = varnum0value =199
Added value
TYpe=1name = varnum1value =200
Added value
TYpe=2name = varnum2value =201
Added value
TYpe=3name = varnum3value =202
Added value
TYpe=4name = varnum4value =203
Added value
TYpe=5name = varnum5value =204
Added value
TYpe=6name = varnum6value =205
Added value
TYpe=7name = varnum7value =206
Added value
TYpe=8name = varnum8value =207
Added value
TYpe=9name = varnum9value =208
Size = 1
Type = 0Name = varnum0value= 199
#g++ -DTHIS_WORKS test.cpp
# ./a.out
Added value
TYpe=0name = varnum0value =199
Added value
TYpe=1name = varnum1value =199
Added value
TYpe=2name = varnum2value =100
Added value
TYpe=3name = varnum3value =100
Added value
TYpe=4name = varnum4value =100
Added value
TYpe=5name = varnum5value =100
Added value
TYpe=6name = varnum6value =100
Size = 7
Type = 0Name = varnum0value= 199
Type = 1Name = varnum1value= 199
Type = 2Name = varnum2value= 100
Type = 3Name = varnum3value= 100
Type = 4Name = varnum4value= 100
Type = 5Name = varnum5value= 100
Type = 6Name = varnum6value= 100
File : test.cpp
#include "uv_type.h"
int main(const int argc, const char **argv)
{
UserVariable uv;
char name[10];
char var[20];
#if defined (DOESNT_WORK)
for (int i = 0; i < 10; i++)
{
sprintf(name, "varnum%d", i);
sprintf(var, "%d", i + 199);
uv.AddUserVar(i, name, var);
}
#endif
#if defined (THIS_WORKS)
uv.AddUserVar(0, "varnum0", "199");
uv.AddUserVar(1, "varnum1", "199");
uv.AddUserVar(2, "varnum2", "100");
uv.AddUserVar(3, "varnum3", "100");
uv.AddUserVar(4, "varnum4", "100");
uv.AddUserVar(5, "varnum5", "100");
uv.AddUserVar(6, "varnum6", "100");
#endif
uv.Print();
return 0;
}
file: uv_type.h
#ifndef UV_TYPE_H
#define UV_TYPE_H
#include
#include
typedef struct
{
int type;
char name[40];
char data[80];
}
UserVar;
typedef std::mapUVTable;
typedef UVTable::value_type UVEntry;
class UserVariable
{
public:
UserVariable() {}
~UserVariable() {}
int AddUserVar(int type, char *name, char *value)
{
UserVar var;
int ret = 0;
UVTable::iterator iter;
var.type = type;
if (strlen(name) < 40)
{
strcpy(var.name, name);
}
else
{
return 1;
}
if (strlen(value) < 80)
{
strcpy(var.data, value);
}
else
{
return 1;
}
UVEntry entry(name, var);
tbl.insert(UVEntry(name, var));
std::cout << "Added value" << std::endl;
std::cout << "TYpe=" << type << "name = "<< name << "value ="
<< value << std::endl;
return 0;
}
int DelUserVar(int type, char *name)
{
}
void Print()
{
UVTable::iterator iter;
std::cout << "Size = " << tbl.size() << std::endl;
for (iter = tbl.begin(); iter != tbl.end(); iter++)
{
UserVar &var = iter->second;
std::cout << "Type = " << var.type
<< "Name = " << var.name
<< "value= " << var.data << std::endl;
}
}
protected:
UVTable tbl;
};
#endif
--
Summary: bug in g++ a.out for stl::map
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lbana at hotmail dot com
GCC host triplet: Linux 2.6.19-1.2911.6.5.fc6 #1 SMP i686 i686 i386
GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31825
[Bug libstdc++/31825] bug in g++ a.out for stl::map
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-04 23:05 --- I don't think this is a bug as you changing the key from underneath of std::map. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31825
[Bug libgcj/31659] config-int.h:327:1: error: "INT8_MIN" redefined
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-04 23:10 --- Subject: Re: config-int.h:327:1: error: "INT8_MIN" redefined > and compilation complains about: > /export/data/devel-test/gcc-svn/trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Messages.java:64: > warning: visibility attribute not supported in this configuration; ignored I also see lots of these on hppa*-hp-hpux11*. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31659
[Bug libstdc++/31826] New: Invalid read of size 1
Dears Valgrind reports me something shown below. ==1193== Invalid read of size 1 ==1193==at 0x4023694: strcpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1193==by 0x41D8837: (below main) (in /lib/libc-2.5.so) ==1193== Address 0x42F1455 is 13 bytes inside a block of size 15 free'd ==1193==at 0x4020FEC: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==1193==by 0x413EDDC: std::string::_Rep::_M_destroy(std::allocator const&) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) Regards. -- Summary: Invalid read of size 1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shw_mail at wp dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31826
[Bug libffi/31574] FAIL: libffi.call/cls_6byte.c -O3 output pattern test
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:43 --- This test is no longer failing. I believe that the problem was fixed by this change: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31574
[Bug middle-end/31493] FAIL: gcc.c-torture/execute/991118-1.c execution at -Os and -O3
--- Comment #4 from danglin at gcc dot gnu dot org 2007-05-04 23:46 --- This test is no longer failing. I believe that this problem was fixed by this change: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31493
[Bug middle-end/31492] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and above
--- Comment #3 from danglin at gcc dot gnu dot org 2007-05-04 23:48 --- This test is no longer failing. I believe that the problem was fixed by this change: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31492
[Bug testsuite/31168] FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:53 --- *** This bug has been marked as a duplicate of 30459 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31168
[Bug testsuite/30459] FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:53 --- *** Bug 31168 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30459
[Bug other/31827] New: limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ - O0 -w -fno-show-column -c -o limits-exprparen.o /test/gnu/gcc/gcc/gcc/testsuit e/gcc.c-torture/compile/limits-exprparen.c(timeout = 300) ^M Pid 2297 received a SIGSEGV for stack growth failure.^M Possble causes: insufficient memory or swap space,^M or stack size exceeded maxssiz. ^M xgcc: Internal error: Segmentation fault (program cc1) Fails at all optimizations. -bash-2.05b$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --disable-nls --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.3.0 --host=hppa64-hp-hpux11.11 --enable-threads=posix --disable-libmudflap --with-gmp=/opt/gnu64/gcc/gcc-4.3.0 --enable-languages=c,c++,fortran,objc,obj-c++,java Thread model: posix gcc version 4.3.0 20070503 (experimental) -- Summary: limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827
[Bug testsuite/31828] New: FAIL: gcc.dg/float-range-[3-5].c (test for excess errors)
FAIL: gcc.dg/float-range-3.c (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: 'FP_INFINITE' undeclared (first use in this function) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: (Each undeclar ed identifier is reported only once /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: for each funct ion it appears in.) -- Summary: FAIL: gcc.dg/float-range-[3-5].c (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31828
[Bug libstdc++/31825] bug in g++ a.out for stl::map
--- Comment #2 from pcarlini at suse dot de 2007-05-05 00:11 ---
You are only passing around a pointer to name and not allocating memory for the
various "C" strings, instead overwriting each time in the loop the same char
array. Well, there are also other problems in the code, like not passing to
std::map as third template argument an appropriate comparison object:
struct ltstr
{
bool operator()(const char* s1, const char* s2) const
{
return std::strcmp(s1, s2) < 0;
}
};
I would suggest always using std::string, instead of "C" strings, at least
while you are still learning std::map.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31825
[Bug libstdc++/31826] Invalid read of size 1
--- Comment #1 from pcarlini at suse dot de 2007-05-05 00:12 --- We need self-contained, minimal code, before taking any further action. Thanks. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31826
[Bug c++/31829] New: FAIL: g++.dg/warn/multiple-overflow-warn-3.C (test for warnings, line 8)
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/ multiple-overflow-warn-3.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11. 11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpu x11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/g nu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsu ite/util -fmessage-length=0 -Woverflow -S -o multiple-overflow-warn-3.s (t imeout = 300) PASS: g++.dg/warn/multiple-overflow-warn-3.C (test for bogus messages, line 8) FAIL: g++.dg/warn/multiple-overflow-warn-3.C (test for warnings, line 8) PASS: g++.dg/warn/multiple-overflow-warn-3.C (test for excess errors) -- Summary: FAIL: g++.dg/warn/multiple-overflow-warn-3.C (test for warnings, line 8) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31829
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-05 00:29 --- Created an attachment (id=13512) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13512&action=view) Documentation patch (not corrupted, this time) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Attachment #13510|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug target/31830] New: Input parameter trashed with optimization -O when using a union and bit field
This occurs with a cross compilation from i386-linux to powerpc-elf. The input
parameter in r3 gets overwritten by the return value from a function call.
This only occurs when optimization is enabled (-O1 or higher). This has
something to do with unions and bit fields. A simple test case follows.
foo.c:
extern int bar1(void);
extern void bar2(int);
void foo(char x)
{
union {
int val;
struct {
unsigned a: 8;
} f;
} u;
u.val = bar1();
u.f.a = x;
bar2(u.val);
}
Here is the assembly:
foo:
stwu 1,-16(1)
mflr 0
stw 0,20(1)
bl bar1
rlwimi 3,3,24,0,7
bl bar2
lwz 0,20(1)
mtlr 0
addi 1,1,16
blr
The input paramter to foo() is passed in r3. r3 is not saved before calling
bar1(), and bar1() returns its value in r3, thereby overwriting the input value
of r3. But the input value of r3 is required in the next instruction 'rlwimi
3,3,24,0,7'.
This works with gcc 3.3.1. It also works with gcc 4.1.2 targetted for
mipsisa32-elf. It fails with gcc 4.1.2 targetted for powerpc-elf. My target
is an embedded system with no OS.
Here is how I build this:
$ /usr/local/trpz/trpz4.1/bin/powerpc-elf-gcc -v -save-temps -Wall -c -O -o
foo.o foo.c
Using built-in specs.
Target: powerpc-elf
Configured with: ../gcc-4.1.2/configure --prefix=/usr/local/trpz/trpz4.1
--target=powerpc-elf --enable-64-bit-bfd --disable-libssp
Thread model: single
gcc version 4.1.2
/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../libexec/gcc/powerpc-elf/4.1.2/cc1
-E -quiet -v -iprefix
/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../lib/gcc/powerpc-elf/4.1.2/
foo.c -Wall -O -fpch-preprocess -o foo.i
ignoring nonexistent directory
"/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../lib/gcc/powerpc-elf/4.1.2/../../../../powerpc-elf/sys-include"
ignoring nonexistent directory
"/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../lib/gcc/powerpc-elf/4.1.2/../../../../powerpc-elf/include"
ignoring duplicate directory
"/usr/local/trpz/trpz4.1/lib/gcc/powerpc-elf/4.1.2/include"
ignoring nonexistent directory
"/usr/local/trpz/trpz4.1/lib/gcc/powerpc-elf/4.1.2/../../../../powerpc-elf/sys-include"
ignoring nonexistent directory
"/usr/local/trpz/trpz4.1/lib/gcc/powerpc-elf/4.1.2/../../../../powerpc-elf/include"
#include "..." search starts here:
#include <...> search starts here:
/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../lib/gcc/powerpc-elf/4.1.2/include
End of search list.
/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../libexec/gcc/powerpc-elf/4.1.2/cc1
-fpreprocessed foo.i -quiet -dumpbase foo.c -auxbase-strip foo.o -O -Wall
-version -o foo.s
GNU C version 4.1.2 (powerpc-elf)
compiled by GNU C version 3.2 20020903 (Red Hat Linux 8.0 3.2-7).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=129090
Compiler executable checksum: bd93f7309b7da302bc5e08433888e36b
/home/gary/trpz/tools/i386-redhat-linux/trpz4.1/bin/../lib/gcc/powerpc-elf/4.1.2/../../../../powerpc-elf/bin/as
-mppc -many -V -Qy -o foo.o foo.s
GNU assembler version 2.17 (powerpc-elf) using BFD version 2.17
My host system is:
$ uname -por
2.6.20-1.2948.fc6 i686 GNU/Linux
--
Summary: Input parameter trashed with optimization -O when using
a union and bit field
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmorain at gmail dot com
GCC host triplet: i386-linux-gnu
GCC target triplet: powerpc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31830
[Bug target/31830] Input parameter trashed with optimization -O when using a union and bit field
--- Comment #1 from gmorain at gmail dot com 2007-05-05 00:47 --- Created an attachment (id=13513) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13513&action=view) Source that demonstrates the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31830
