[forwarded from http://bugs.debian.org/276843]
- gcc-3.4.3 -O2 -Wall foo.c doesn't print the warning
foo.c: In function `foo':
foo.c:2: warning: control reaches end of non-void function
gcc-3.3.4 does.
- gcc-4.0 does print a warning, but the warning in 3.3 was
more meaningful for the
--
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18588
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-21
09:07 ---
IIRC note luids are supposed to be a superset of regular luids, so your check
should be redundant (see regclass.c:reg_scan_mark_refs). Now something could
have invalidated this relationship.
It's
[forwarded from http://bugs.debian.org/268115]
Matthias
The bug submitter writes:
compiling this function:
double baz(double foo, double bar)
{
return foo*foo*foo*foo*bar*bar*bar*bar;
}
on amd64 with -O6 -ffast-math, gcc emits this code:
foo.o: file format elf64-x86-64
Disassembly
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-21
10:08 ---
(In reply to comment #1)
What is the difference between f and the standardized versions of fortran?
F is a subset of Fortran 95.
A list of features not in F95 is at
[forwarded from http://bugs.debian.org/262658]
on m68k-linux, the attached testcase ICEs with 3.2.3, 3.3.5, 3.4.3, not with
3.0.4, 4.0 currently does not bootstrap on m68k-linux
Matthias
$ gcc-3.4 -c -O2 config.i
config.c: In function `readConfigFile':
config.c:1052: internal compiler error:
--
What|Removed |Added
Known to fail||3.2.3 3.3.5 3.4.3
Known to work||3.0.4
--- Additional Comments From debian-gcc at lists dot debian dot org
2004-11-21 10:59 ---
Created an attachment (id=7574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7574action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18590
[forwarded from http://bugs.debian.org/277845]
rechecked with HEAD CVS 20041113.
Matthias
The bug submitter writes:
$ cat namel.inp
foo
a= 2.30,/
$ cat namel-tst.f90
program sechs_w
implicit none
integer, parameter :: dr=selected_real_kind(15)
integer, parameter ::
[forwarded from http://bugs.debian.org/270340]
works with 3.2.3, fails with 3.3.5 and 3.4.3.
Matthias
gcc -I/build/buildd/erlang-9.2.2/erts/emulator/beam -g -O2
-I/build/buildd/erlang-9.2.2/erts/m68k-unknown-linux-gnu
+-DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes
--- Additional Comments From debian-gcc at lists dot debian dot org
2004-11-21 11:44 ---
Created an attachment (id=7575)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7575action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
--
What|Removed |Added
CC||zippel at linux-m68k dot
||org, schwab at suse dot de
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-21
12:17 ---
In addition to the bogus warnings about '__dt' and '__ct' shadowing a
member of 'this' I get three more warnings when compiling a preprocessed
version of #includeiostream. I just stripped the lines
[forwarded from http://bugs.debian.org/272673]
works with 3.0.4, HEAD 20041030, doesn't work with 3.2.3, 3.3.5, 3.4.3.
Matthias
$ gcc-3.4 -O2 -save-temps
-I/build/packages/nmu/freebsd-buildutils-5.2.1+20041028.1/build-tree/src/usr.bin/make
-DMAKE_VERSION=\5200408120\ -DDEFSHELL=1 -O2 -g -Wall
--- Additional Comments From debian-gcc at lists dot debian dot org
2004-11-21 13:14 ---
Created an attachment (id=7576)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7576action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18593
--
What|Removed |Added
Known to fail||3.2.3 3.3.5 3.4.3
Known to work||3.0.4 3.4.0
Summary|[3.3 / 3.4
--- Additional Comments From pcarlini at suse dot de 2004-11-21 13:15
---
Hi. Those typedef are arguably redundant (that code is not very actively worked
on
these days, maybe that will change...) but, IMH, not-language-lawyer, opinion
should not trigger any warning: since, after all,
--
What|Removed |Added
Summary|[3.3 / 3.4 regression] |[3.3 / 3.4 regression] ICE
||in insn_default_length, at
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:10 ---
*** This bug has been marked as a duplicate of 13000 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:10 ---
*** Bug 18588 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:15 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:17 ---
Confirmed, I don't know useful this really is as I seen recently a large number
of bugs about namelist
which is not in F.
Oh, by the way how can they trademark a single letter.
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:24 ---
Confirmed.
Actually the most optimial code would be:
mulsd %xmm1, %xmm0
mulsd %xmm0, %xmm0
mulsd %xmm0, %xmm0
aka
(foo*bar)^4
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:26 ---
*** This bug has been marked as a duplicate of 14838 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
14:26 ---
*** Bug 18593 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14838
--
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|3.2.3 |3.2.3 4.0.0
Target Milestone|---
--
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |3.4.4
Using the program in PR 10060, to generate 1000 and 2000, I see that PHI
insertion goes from:
tree PHI insertion: 4.44 (34%) usr 0.03 ( 1%) sys 5.46 (28%) wall
to
tree PHI insertion: 24.92 (48%) usr 1.78 (30%) sys 29.65 (49%) wall
which looks like PHI insertion does not
Using the program in PR 10060, to generate 1000 and 2000, I see that IV OPT
goes from:
tree iv optimization : 1.79 (14%) usr 0.15 ( 5%) sys 2.60 (13%) wall
to
tree iv optimization : 6.92 (13%) usr 0.29 ( 5%) sys 7.30 (12%) wall
which looks like PHI iv opt does not scale O(n).
With the testcase in 12322, we get an ICE after errors because of nested
functions.
Reduced testcase:
int f(int i)
{
static int g();
static int g() { return i; }
return g();
}
: Search converges between 2004-07-27-trunk (#496) and 2004-07-28-trunk (#497).
--
Summary: [4.0
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18596
--- Additional Comments From dnovillo at redhat dot com 2004-11-21 15:22
---
Subject: Re: [4.0 Regression] bootstrap comprison
failed
On Sun, 2004-11-21 at 08:02 -0700, Jeffrey A Law wrote:
Since I've been unable to trigger the failure here, I can't say for
certain whether
--- Additional Comments From hjl at lucon dot org 2004-11-21 15:53 ---
gnucompare has passed on Linux/ia64, Linux/ia32 and Linux/x86_64 now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
15:55 ---
I am testing it right now on ppc-darwin too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
This error was encountered in building the NetCDF fortran90 test programme
with gfortran.
Numerical constants appear to be integer*4 and the +ve and -ve limits are
fixed to the same magnitude.
PROGRAM test_min
INTEGER(KIND=4),PARAMETER :: ikind=0
integer(kind=4) :: itest = -HUGE(ikind)-1
PROGRAM test_kind
integer :: itest
REAL:: rtest
itest = HUGE(itest)
rtest = HUGE(rtest)
print * , ' itest = ', itest , '\n rtest = ' , rtest
! Try multipling by two, since numerical consts are KIND=4
print * , ' 2*itest = ', 2 * itest , '\n 2*rtest = ' , 2 * rtest
END PROGRAM test_kind
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
16:18 ---
*** This bug has been marked as a duplicate of 13464 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
16:18 ---
*** Bug 18598 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
16:19 ---
*** This bug has been marked as a duplicate of 17912 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
16:19 ---
*** Bug 18597 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-21
16:29 ---
Subject: Re: numerical constant arithmetic overflow with integer(kind=4)
*** This bug has been marked as a duplicate of 17912 ***
agreed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18597
--- Additional Comments From gerrit at gcc dot gnu dot org 2004-11-21
16:30 ---
(In reply to comment #1)
Text mode is the default at least according to C89 so the bug is in cygwin and
not GCC.
If you want a file to be mode 'A' then read/write it in this mode explicitly.
You cannot
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
16:34 ---
But since the C standard says it is in text mode by default, it is the
underlaying OS to do that and not to
mess up. Also the C standard says to enable binary mode by using the b mode.
--
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-21
16:38 ---
Subject: Re: -i8 and -d8 compiler options do nothing / -r8 not recognised
*** This bug has been marked as a duplicate of 13464 ***
agreed
It seems that by additional comment #10 you were all hot on
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
17:11 ---
Fixed so closing.
--
What|Removed |Added
Status|ASSIGNED
The following variant of PR15524 takes a lot of time in regrename.
I use -O2 -fno-gcse to make regrename stand out.
#define CL0(a) case a: return a;
#define CL1(a) CL0(a##0) CL0(a##1) CL0(a##2) CL0(a##3) CL0(a##4) CL0(a##5) \
CL0(a##6) CL0(a##7) CL0(a##8) CL0(a##9)
#define CL2(a) CL1(a##0)
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|UNCONFIRMED
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-21 17:58
---
I've got a patch. I'll test it shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18599
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-21
18:12 ---
Testing it on sparc-sun-solaris2.5.1, sparc-sun-solaris2.6 and
i586-redhat-linux-gnu...
OK on the 3 platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
[EMAIL PROTECTED] debug]$ f95 554RED.f
554RED.f: In function MAIN__:
554RED.f:8: internal compiler error: in gfc_add_modify_expr, at
fortran/trans.c:154
The code is as follows:
PROGRAM FM020
LOGICAL LFTN01, LDTN0100250020
C. TEST
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
18:47 ---
Confirmed.
--
What|Removed |Added
OtherBugsDependingO||17423
Related to PR 15524 but unlike that case where we are the same compile time for
that test, this one we
are three times slower.
#define CL0(a) case a: b=a+1; goto c;
#define CL1(a) CL0(a##0) CL0(a##1) CL0(a##2) CL0(a##3) CL0(a##4) CL0(a##5) \
CL0(a##6) CL0(a##7) CL0(a##8) CL0(a##9)
#define
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
21:15 ---
Most (95%) of the time is spent updating the dominator information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
21:16 ---
The loop which is taking the time is tree-cfg.c:4085-4099.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-21 21:43
---
If you call free_dominance_info in cleanup_tree_cfg.c right before
calling thread_jumps, the compile time problem basically vanishes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18601
--
Bug 18326 depends on bug 18324, which changed state.
Bug 18324 Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure:
gcc.c-torture/execute/20010518-2.c execution, -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18324
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
21:51 ---
This has been fixed for 5 days now, closing.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
21:55 ---
This is now back to 3.3 timings so closing, I filed PR 18601 for another case
where tree cfg cleanup is
slow, it is a variant of this testcase but I have seen the same problem in
another testcase but I
--- Additional Comments From law at redhat dot com 2004-11-21 22:18 ---
Subject: Re: [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases
On Sun, 2004-11-21 at 21:55 +, pinskia at gcc dot gnu dot org wrote:
--- Additional
--- Additional Comments From giovannibajo at libero dot it 2004-11-21
22:52 ---
It looks like the testcase in this bug (and the related bugs and duplicates)
is invalid. But I am not sure if it used to be accepted thanks to a GCC
extension we want to prefer. Can someone elaborate on
--- Additional Comments From giovannibajo at libero dot it 2004-11-21
22:54 ---
I am sure that Jeff can use Bugzilla himself, when he wants this bug closed.
--
What|Removed |Added
--- Additional Comments From schwab at suse dot de 2004-11-21 22:59 ---
This is the change that triggers the bug:
Sun Jul 21 00:54:54 CEST 2002 Jan Hubicka [EMAIL PROTECTED]
* gcse.c: Include cselib.h
(constptop_register): Break out from ...
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
23:07 ---
Confirmed.
static struct gnat__strings__string_list_access C.572 = {.P_ARRAY=(struct
gnat__strings__string_access[(long int) PLACEHOLDER_EXPR struct
gnat__strings__string_list_access.P_BOUNDS-LB0 ..
Here is basically the same testcase as PR18599 except that
we have more switch cases. This testcase segfaults.
cc1 is from today's mainline with checking disabled.
#define CL0(a) case a: return a;
#define CL1(a) CL0(a##0) CL0(a##1) CL0(a##2) CL0(a##3) CL0(a##4) CL0(a##5) \
CL0(a##6) CL0(a##7)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
23:20 ---
Confirmed, the problem is because of stack overflow.
Either splay_tree_delete_helper needs a little help or the C/C++ front-end
needs to stop using splay
trees.
#553 0x0033a4a0 in
GCC uses local label names .L1, .L2, etc. on this platform.
However these same assembly labels are used for functions named L1 or L2.
[EMAIL PROTECTED] wolfgang $ cat L.c
int L2(int x)
{
if(x 5)
return -42;
else
return 42;
}
[EMAIL PROTECTED]
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-21 23:22
---
still segfaults with checking enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18599
--- Additional Comments From kazu at cs dot umass dot edu 2004-11-21 23:27
---
Sorry, comment #2 was meant for PR18602.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18599
--- Additional Comments From pcarlini at suse dot de 2004-11-21 23:39
---
Hi again. As expected, fpfinal3 regtests Ok on x86/x86_64/ia64-linux. I'm
attaching what I have actually tested: doesn't include the regenerated files and
avoids a warning about the unused __mod argument of
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
23:58 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
00:07 ---
Oh, I think I have a fix, testing it right now, basically we need to unshare
the expression before
gimplifying the DECL's initialize.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-11-22
00:17 ---
This was not fixed by the patch for PR 509 because that fix affects a part of
code which is executed only for functions, not variables.
I'm looking into this right now.
--
--- Additional Comments From shebs at apple dot com 2004-11-22 00:24
---
Subject: Re: [4.0 Regression] bootstrap comprison failed
Jeffrey A Law wrote:
I've been unable to reproduce the comparison failures. However, as I
outlined in an earlier message, I have come up with a
--- Additional Comments From giovannibajo at libero dot it 2004-11-22
00:47 ---
I am not sure what we are supposed to do with this. Any kind of tree traversal
and deletion is inherently recursive, and will hit a segfault sooner or later,
if you push it hard enough. If an user really
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
00:50 ---
Use a seperate stack instead of using function stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18602
--- Additional Comments From giovannibajo at libero dot it 2004-11-22
00:51 ---
Confirmed:
18596.c: In function 'f':
18596.c:3: error: invalid storage class for function 'g'
18596.c:4: error: invalid storage class for function 'g'
--
What|Removed
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2004-11-22 01:08 ---
This bug report can be closed. Both the alias for RAN and Janne's
handling of specifying the requisite standard have been in the
gfortran tree for quite sometime.
--
steve
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
01:09 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2004-11-22 01:13 ---
I've implemented this in accordance with the g77 info file.
http://gcc.gnu.org/ml/fortran/2004-11/msg00149.html
I doubt that it will ever be committed.
--
steve
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-22
01:21 ---
Subject: Bug 17836
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-22 01:21:11
Modified files:
gcc: ChangeLog
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2004-11-22 01:43 ---
Toon, Don't you have commit access to the tree? You can fix this
under the obvious rule.
--
steve
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-22
02:13 ---
Subject: Bug 18520
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-22 02:13:15
Modified files:
gcc: ChangeLog dojump.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
02:20 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01724.html.
I am now able to build the Ada compiler on ppc-darwin with the patch above and
the patch for PR
18217.
--
What
--- Additional Comments From olivier_thomann at ca dot ibm dot com
2004-11-22 02:20 ---
So where should I report this bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18550
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
02:22 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
02:27 ---
http://www.mingw.org/bugs.shtml
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18550
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
02:36 ---
A more reduced testcase:
struct iterator {
int i;
iterator operator++(int);
void _M_bump_up();
};
iterator iterator::operator++(int) {
iterator __tmp = *this;
_M_bump_up();
return __tmp;
}
--
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-06-06
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2004-11-22 04:19 ---
Toon,
I take it back. The code as written is correct. DCONJG is not
listed in 13.6 Specific names for standard intrinsic functions
of the current standard. It you change the code, then
The following code fails to compile on 3.4 and newer compilers:
-
#include functional
struct less : public std::lessint
{};
#include set
-
$ g++-3.4 -c test.cc
In file included from
--- Additional Comments From giovannibajo at libero dot it 2004-11-22
05:05 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01729.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
05:10 ---
I think the problem is that the attribute strong is not strong enough.
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2004-11-22 06:36
---
Patch, rev. 2, waiting review:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01469.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
06:39 ---
Zdenek since you added the code to thread_jumps to incremental update the DOM
information, could
you comment on this bug?
(Note I have seen this in more than just this testcase which is superficial).
I
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-22
07:12 ---
The way to fix this is before going out of SSA to have another HOST_WIDE_INT in
INDIRECT_REF to say
the aliasing set for that tree.
And also add this patch which looks at the use defs:
Index: alias.c
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
98 matches
Mail list logo
