Consider the following code:
void func ()
{
}
void func2 ()
{
return func ();
}
gcc -pedantic correctly warns about "return func();", but the warning text is
very confusing:
'return' with a value, in function returning void
It talks about "value" where there is no value involved.
It took
--- Comment #15 from pault at gcc dot gnu dot org 2006-10-20 04:50 ---
Jerry,
I got your message and will reply later - I have to run for the bus!
I have been aware that there is a problem with empty symbols for some little
while. Whilst on the way to the lab, I will contemplate how t
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:54
---
Another test case with similar error:
program friend
character*20 y, x 0
data y /'abcdef'/, x /'jbnhjk'/ o
print *, "basketcase"
end program friend
$ gfc pr27954.f90
In file pr27954.f90:2
character*2
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26
---
*** Bug 18923 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26
---
*** This bug has been marked as a duplicate of 27954 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:24
---
I believe this is a duplicate of PR18923. What I am finding is that under some
error conditions, we end up with empty symbols. When gfc resolve is executed
we are bumping into this arror because the sym->name i
--- Comment #4 from daney at gcc dot gnu dot org 2006-10-20 01:10 ---
Caused by commit r117143
Thanks to Andrew Pinski for helping me find it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
--- Comment #9 from hubicka at ucw dot cz 2006-10-19 23:32 ---
Subject: Re: compile time hog / deadloop.
Just for a record, we discussed this a bit on IRC. I origionally wrote
that loop copying logic from alias.c just to be sure that all the fields
from base clases are merged into the
--- Comment #5 from pcarlini at suse dot de 2006-10-19 23:29 ---
Ah, interesting! Therefore, if I understand correctly DR 106, when the C++
front-end will implement the resolution, this kind of bind2nd usage will
magically start working without changing at all the library... On the other
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 23:16 ---
The difference between with and without -fnon-call-exceptions is:
insn 10 9 11 3 (set (reg/f:SI 196)
(mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) -1
(nil)
(nil))
vs:
(insn 10 9 11 3 (set (re
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-19 23:10 ---
Expand does:
;; return t->f13 == 4294967295B
(insn 10 9 11 (set (reg/f:SI 196)
(mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) -1
(nil)
(nil))
(insn 11 10 12 (set (reg:SI 198)
(plus:SI
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-10-19 23:07
---
Fixed.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-10-19 23:07 ---
Fixed.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #44 from dberlin at gcc dot gnu dot org 2006-10-19 23:07
---
Fixed.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #43 from dberlin at gcc dot gnu dot org 2006-10-19 23:06
---
Subject: Bug 28778
Author: dberlin
Date: Thu Oct 19 23:05:53 2006
New Revision: 117891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891
Log:
2006-10-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-10-19 23:06
---
Subject: Bug 29415
Author: dberlin
Date: Thu Oct 19 23:05:53 2006
New Revision: 117891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891
Log:
2006-10-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-10-19 23:06 ---
Subject: Bug 29156
Author: dberlin
Date: Thu Oct 19 23:05:53 2006
New Revision: 117891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891
Log:
2006-10-19 Daniel Berlin <[EMAIL PROTECTED]>
Fix P
--- Comment #1 from daney at gcc dot gnu dot org 2006-10-19 22:54 ---
Created an attachment (id=12465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12465&action=view)
Dumps from -da with and without -fnon-call-exceptions
The dump files in da-dumps.tgz named isprimb.c.* are from:
--- Comment #2 from echristo at apple dot com 2006-10-19 22:24 ---
I'll take a look at this.
--
echristo at apple dot com changed:
What|Removed |Added
AssignedTo|
--- Comment #1 from pcarlini at suse dot de 2006-10-19 22:22 ---
Will fix as soon as I'm nack from a travel...
--
pcarlini at suse dot de changed:
What|Removed |Added
This is an internal reminder for an issue which must be fixed before delivering
the discrete distributions (geometric, poisson, binomial, in particular): when,
in operator(), the floating point result exceeds the max integer value of the
return type the value must be rejected.
--
Summ
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-19 22:16
---
The generated code emitted for the TRANSPOSE for i386-darwin is stupid:
atmp.13.dtype = parm.12.dtype;
atmp.13.dim[0].stride = parm.12.dim[1].stride;
atmp.13.dim[0].lbound = parm.12.dim[1].lbound;
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-19 21:59 ---
(In reply to comment #7)
> missing "int".
That is because we did not error out on it in 3.3.3 or 3.4.0 for that matter, I
wonder why.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-19 21:58 ---
Note bool has nothing to do with the problem, the following testcase shows
that:
template< int C > int assertion_failed( int);
template< class >
struct N
{
static int const okay = 1;
enum {
t = sizeof( asser
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #18 from likewise at gmx dot net 2006-10-19 22:01 ---
Created an attachment (id=12464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12464&action=view)
Fix.
Copied from
http://www.freaknet.org/martin/crosstool/patches/gcc-4.1.1/gcc-4.1.1-bugfix-27363.patch
so that it l
This is a reduced testcase from a failure I am seeing on libgcj testsuite.
java.lang.Class.isPrimitive() is being compiled incorrectly.
This is a regression from 3.4.3.
Configured as: ../clean/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipse
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:59
---
It's still not working for RESHAPE. Uncomment the test_reshape line in the
newly added zero_sized_1.f90 test and see how it fails :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail||4.0.2 4
--- Comment #7 from gdr at cs dot tamu dot edu 2006-10-19 21:57 ---
Subject: Re: diagnostic on correct code; regression from
3.4.4
On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote:
| Reduced testcase:
Very nice.
| template< bool C > int assertion_failed( int);
| template<
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-19 21:54 ---
Reduced testcase:
template< bool C > int assertion_failed( int);
template< class >
struct N
{
static bool const okay = true;
enum {
t = sizeof( assertion_failed( 0))
};
};
main()
{
N n;
}
--
http
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:49
---
Subject: Bug 27895
Author: fxcoudert
Date: Thu Oct 19 21:48:50 2006
New Revision: 117890
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117890
Log:
PR libfortran/27895
* intrinsics/cshif
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-19 21:42 ---
Reducing through a nice trick of using delta and using 3.3.x as the base
compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
--- Comment #4 from gdr at cs dot tamu dot edu 2006-10-19 21:32 ---
Subject: Re: incorrect "
On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote:
| I tried a simple testcase and variations on it (changing (T)(ok) to just ok
and
| such):
yes, the parens don't change anything --
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 21:27 ---
I tried a simple testcase and variations on it (changing (T)(ok) to just ok and
such):
template class b{};
template class t
{
static bool const ok = true;
b<(T)(ok)> c;
};
int main(void)
{
t a;
}
--
ht
--- Comment #2 from wb at fnal dot gov 2006-10-19 21:22 ---
Created an attachment (id=12463)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12463&action=view)
preprocessed version of test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-19 21:19 ---
Yes we need the preprocessed source.
You can attach it to the bug report instead of just copying and pasting it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Regression from gcc 3.4.4; under gcc 4.1.1 it produces the diagnostic "error:
'N::okay' is not a valid template argument for type 'bool' because it is a
non-constant expression" -- and I am informed (by gdr) that the bug is still
present in gcc 4.2.0.
The code below makes use of the Boost library;
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-19 20:47 ---
Btw. - completely killing the BINFO walking bootstraps and regtests ok...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-19 20:45 ---
I wonder why we walk the class hierarchy using the BINFOs at all. It contains
lots of recursively empty structures - maybe better just walk the TYPE_FIELDS
list recursively?
--
rguenth at gcc dot gnu dot org cha
--- Comment #6 from hubicka at ucw dot cz 2006-10-19 19:36 ---
Subject: Re: compile time hog / deadloop.
>
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-19 15:15
> ---
> It _looks_ like we're needlessly recursing into the BINFOs in the i386
> backend.
Wha
--- Comment #8 from sje at cup dot hp dot com 2006-10-19 18:09 ---
Well, I found that the TImode is getting introduced in layout_type. For an
ARRAY_TYPE tree there is this line:
TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 18:06 ---
This is most likely a dup of bug 28116 anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
--- Comment #3 from fang at csl dot cornell dot edu 2006-10-19 18:03
---
ping? ice-on-valid in boost
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
--- Comment #3 from ppluzhnikov at charter dot net 2006-10-19 17:34 ---
Here is another (very similar) test case:
template struct Dict {
struct Iterator;
Iterator begin() { return Iterator(); } // incomplete
};
template struct Dict::Iterator { Iterator() { } };
--
h
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 17:14 ---
(In reply to comment #2)
> "make bootstrap" produces a different error; I'll try building just the C
> compiler next (even if gcj is what I'm really after).
After that finishes, you should bootstrap the compiler wit
--- Comment #3 from Ulrich dot Beingesser at t-systems dot com 2006-10-19
17:02 ---
(In reply to comment #2)
> -lpthread
> I think that is your problem, you should be using -pthread instead.
> Can you try using -pthread instead of -lpthread?
Using -pthread instead of -lpthread shows th
--- Comment #2 from billt at tutsys dot com 2006-10-19 17:01 ---
"make bootstrap" produces a different error; I'll try building just the C
compiler next (even if gcj is what I'm really after).
/tmp/gcc-4.1.1/820/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.1.1/820/./gcc
-nostdinc++ -L/tmp/gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-19 16:51 ---
-lpthread
I think that is your problem, you should be using -pthread instead.
Can you try using -pthread instead of -lpthread?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
--- Comment #1 from Ulrich dot Beingesser at t-systems dot com 2006-10-19
16:45 ---
Created an attachment (id=12462)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12462&action=view)
Test program that demonstrates the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
The attached code crashes under AIX5.2 and AIX5.3 when compiled with g++ 4.1.1.
The effect also occurs using g++ 4.0.3.
It seems that throwing exceptions is not completely thread safe.
The crash symptom is one of:
1. segmentation fault (core dumped)
2. illegal instruction (core dumped)
3. termina
--- Comment #9 from janis at gcc dot gnu dot org 2006-10-19 16:35 ---
I wasn't able to do a regression hunt for the fix on the mainline because I
didn't find any revision for which the test failed on the mainline.
A regression hunt on the 4.1 branch using the testcase from comment #7 wi
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-10-19 15:45
---
Subject: Bug 29413
Author: rsandifo
Date: Thu Oct 19 15:45:46 2006
New Revision: 117886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117886
Log:
gcc/
Backport from mainline:
2006-10-17
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-19 15:15 ---
It _looks_ like we're needlessly recursing into the BINFOs in the i386 backend.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-19 14:58
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 14:52 ---
*** Bug 29515 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 14:52 ---
To close as a dup of bug 7412.
*** This bug has been marked as a duplicate of 7412 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 14:51 ---
Actually this is valid C++ via DR 106.
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pluto at agmk dot net 2006-10-19 14:46 ---
(In reply to comment #3)
> (it's probably not really dead here, just taking a long time to complete, as
> finishing earlier frames takes more and more time)
compilation for i486 target takes ~20 seconds and ~300MB of memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-19 14:31 ---
I can confirm this. We are gimplifying some large tree(s) like
#150 0x005257ff in gimplify_stmt (stmt_p=0x7fffcff543e8)
at /space//rguenther/src/svn/gcc-4_1-branch/gcc/gimplify.c:4028
4028 gimplify
--- Comment #7 from l_heldt at poczta dot onet dot pl 2006-10-19 13:51
---
(In reply to comment #2)
> Please attach a complete test case, not a sketch.
>
> -benjamin
>
This bug is a pure race-condition. There is no test case which would reveal it
with a 100% certainty. I have noticed
--- Comment #2 from pcarlini at suse dot de 2006-10-19 13:10 ---
This is a well knows issue with the current standard binders, see, for example:
http://gcc.gnu.org/ml/libstdc++/2000-06/msg00210.html
It is possible to extend the implementation, but the real way to go is moving
to the
--- Comment #1 from patchapp at dberlin dot org 2006-10-19 12:50 ---
Subject: Bug number PR29507
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/2006-10/msg00984.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from patchapp at dberlin dot org 2006-10-19 12:35 ---
Subject: Bug number PR29490
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/2006-10/msg00983.html
--
http://gcc.gnu.org/bugzilla/sh
=aacantrip
�==bacantrip
���==cacantrip
This is with mainline gfortran:
$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.8.1
Configured with: /gcc/configure --enable-languages=c,fortran
Thread model: posix
gcc version 4.2.0 20061019 (experimental)
The corresponding test results ca
--- Comment #4 from patchapp at dberlin dot org 2006-10-19 12:21 ---
Subject: Bug number PR29387
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/2006-10/msg00982.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from pluto at agmk dot net 2006-10-19 11:54 ---
Created an attachment (id=12461)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12461&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
comeau reports no error, and with stlport5 testcase works fine.
$ g++ -I/usr/include/stlport main.cpp -o main -lstlport && ./main
Hello 1
Hello 2
with libstdc++ i get:
$ g++ main.cpp -o main && ./main
/usr/include/c++/4.1.2/bits/stl_function.h: In instantiation of
‘std::binder2nd >’:
main.cpp:1
--- Comment #16 from irar at gcc dot gnu dot org 2006-10-19 11:18 ---
Subject: Bug 26969
Author: irar
Date: Thu Oct 19 11:18:25 2006
New Revision: 117883
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117883
Log:
Backport from mainline:
2006-08-07 Victor Kaplans
--- Comment #3 from pcarlini at suse dot de 2006-10-19 10:26 ---
not a bug: per section 2.5 of the Standard 'not' is an alternative token for
'!'
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #2 from selalerer at nana dot co dot il 2006-10-19 10:06
---
Created an attachment (id=12460)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12460&action=view)
The *.ii file created by the compiler from the source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from selalerer at nana dot co dot il 2006-10-19 10:05
---
Created an attachment (id=12459)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12459&action=view)
Source file for the code that created the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29514
Look at the source file first, its very short.
$ g++ -c -save-temps main.cpp
main.cpp:4: error: expected unqualified-id before ! token
$ g++ --version
g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying c
--- Comment #2 from pluto at agmk dot net 2006-10-19 09:35 ---
4.1 backtrace:
#0 0x005a65ad in mul_double ()
#1 0x005a70e2 in int_const_binop ()
#2 0x005b0796 in size_binop ()
#3 0x00717d9a in bit_from_pos ()
#4 0x00725157 in bit_position ()
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-19 09:07
---
So that it doesn't get lost, here's another UBOUND problem:
$ cat a.f90
subroutine foo (x,n)
integer x(7,n,2,*)
print *, ubound(x,1)
print *, ubound(x,2)
print *, ubound(x,3)
! print *, ubound(x,4)
!
--- Comment #1 from pluto at agmk dot net 2006-10-19 09:00 ---
Created an attachment (id=12458)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12458&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[4.1] mem usage: ~120MB, compile time: +inf? (canceled after 980 minutes).
[4.2] mem usage: ~90MB, compile time: +inf? (similiar).
--
Summary: compile time hog / deadloop.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
--- Comment #2 from Eric dot Deplagne at nerim dot net 2006-10-19 08:58
---
Should I assume that 40+40 can FPE my ass too, then ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29511
--- Comment #1 from schwab at suse dot de 2006-10-19 08:39 ---
That's not a bug, the result of -2147483648/-1 is overflowing the range of int,
thus invokes undefined behaviour.
--
schwab at suse dot de changed:
What|Removed |Added
-
The division of 0x8000 by -1 gives FPE on both Intel and AMD Processors...
I have checked that with the following simple program on both Fedora core 3's
GCC 3.4.4 and debian sarge's gcc-3.3.5...
I also had someone check it with gcc 4.1.2 and FreeBSD too...
int divide(int a,int b)
{
return
82 matches
Mail list logo