--- Comment #3 from lbana at hotmail dot com 2007-05-05 05:01 ---
Subject: RE: bug in g++ a.out for stl::map
Dear Gnu,
Sorry for logging invalid bug, I should have spend some time in reading it.
I thought all I need to do is pass stack variable. Anyhow thanks for the
advice.
-Laxman
>
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-05-05 03:50
---
Now I have tracked that we have a duplicate expr in the cl_list so that we call
resolve_char_len twice, as the list is traversed in resolve_types. A quick fix
is to bail out of the loop if resolve_char_len retur
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/ctor-9.C
-B/test/gnu/gcc/objdir/hp
pa64-hp-hpux11.11/./libgomp/
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgom
p -I/test/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-len
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/ctor-8.C
-B/test/gnu/gcc/objdir/hp
pa64-hp-hpux11.11/./libgomp/
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgom
p -I/test/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-len
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
--- Comment #3 from hjl at lucon dot org 2007-05-05 02:31 ---
The problem may be patterns like
[(set (match_operand:SI 0 "nonimmediate_operand" "=r,rm,r")
(plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0,0,r")
(match_operand:SI 2 "general_operand" "rmni,
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/integer_exponentiation_3.F90 -O0
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objd
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/integer_exponentiation_2.f90 -O1
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objd
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/assumed_charlen_function_5.f90 -O -pedantic-errors -S -o
ass
umed_charlen_function_5.s(timeout = 300)
/test/gnu/g
--- Comment #5 from patchapp at dberlin dot org 2007-05-05 01:06 ---
Subject: Bug number PR31803
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-05/msg00237.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from patchapp at dberlin dot org 2007-05-05 01:06 ---
Subject: Bug number PR31692
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-05/msg00246.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pcarlini at suse dot de 2007-05-05 00:53 ---
For just an example of user-code error leading to a valgrind message mentioning
std::string::_Rep::_M_destroy, see:
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2006-02/msg00070.html
That's why, mi
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-05 00:50 ---
This is what the standard says is to happen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31816
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-05 00:48 ---
I can reproduce the failure on powerpc-linux-gnu with 4.1.0 but it works on the
trunk. combine is doing something wrong.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- 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
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 follow
--- 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
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/
--- 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
---
--- 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 p
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 onl
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:
--- 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
--- 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
--
--- 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|Remove
--- 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|Remov
--- 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|Remove
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 f
--- 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:
> w
--- 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
# 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 valu
--- 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, t
--- 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
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 repro
--- 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 ev
--- 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
--- 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
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: unass
--- 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/to
--- 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://
--- 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
--- 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 o
--- 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
--- 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]>
--- 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
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
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
--- 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
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 regression] fseek |fseek intrinsic not
|intrinsic not implemented |i
--- 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 no
--- 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]>
--- 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.
--- 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
--- 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
--- 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
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 m
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:
ifo
--- 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
--- 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
--- 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
--- 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 could
"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
--- 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
--- 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
--- 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 *
--- 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)
--- 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|WA
--- 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 un
--- 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
--- 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_l
--- 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 (tra
--- 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))
--- 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
--- 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 &&
--- 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
--- 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
-
--- 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
---
--- 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 fort
--- 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:
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 no
--- 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
--
--- 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
tes
--- 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
--- 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
--- 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
--- 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 perf
--- 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
--- 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 const
--- 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_simp
--- 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
--- 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
--- 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 "
--- 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[](
--- 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
--
--- 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
--- 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|N
--- 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 t
1 - 100 of 117 matches
Mail list logo
