--- Comment #10 from dennis dot wassel at googlemail dot com 2008-11-10
13:32 ---
Subject: Re: RANDOM_SEED: PUT= check array size at compile time
The documentation says only that the size argument has to be an integer. See
http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fSEED.html
--- Comment #8 from uros at gcc dot gnu dot org 2008-11-10 09:09 ---
Subject: Bug 37809
Author: uros
Date: Mon Nov 10 09:08:15 2008
New Revision: 141732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141732
Log:
PR middle-end/37807
PR middle-end/37809
*
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-10 13:34
---
Confirmed, I'll fix it momentarily. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from michael dot a dot richmond at nasa dot gov 2008-11-10
12:59 ---
(In reply to comment #8)
If you check, the minimum size of count is 8 as returned by the size= argument
if you use it. Try this. size is intent OUT.
The documentation says only that the size argument
--- Comment #1 from jakub at gcc dot gnu dot org 2008-11-10 13:43 ---
Subject: Bug 38021
Author: jakub
Date: Mon Nov 10 13:41:37 2008
New Revision: 141739
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141739
Log:
PR c++/38021
* parser.c
--- Comment #2 from paolo at gcc dot gnu dot org 2008-11-10 13:48 ---
Subject: Bug 38067
Author: paolo
Date: Mon Nov 10 13:47:12 2008
New Revision: 141740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141740
Log:
2008-11-10 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-10 13:49
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-10 13:49 ---
Subject: Bug 35314
Author: jakub
Date: Mon Nov 10 13:48:06 2008
New Revision: 141741
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141741
Log:
PR middle-end/35314
* tree-mudflap.c
--- Comment #3 from nickc at redhat dot com 2008-11-10 13:49 ---
Hi Guys,
I have uploaded a potential patch for the problem. It fixes the testcase
originally provided and does not introduce any regressions into the g++
testsuite for an i686-pc-linux-gnu toolchain.
That's the good
--- Comment #11 from michael dot a dot richmond at nasa dot gov 2008-11-10
13:50 ---
(In reply to comment #10)
Admitted, it does not say SIZE = 8, because this value may be
compiler- and system-dependent (may also be 12 for gfortran on some
platforms), which is why the standard
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-10 13:50 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-10 13:52 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-10 13:53 ---
Patch posted.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-10 10:15 ---
2 locations won't help you either.
void foo ()
{
#define EMPTY
while (0)EMPTY;
}
won't warn when compiled with g++ -Wempty-body -O2, but will with
g++ -Wempty-body -O2 -save-temps (i.e. ccache etc.). I think it is
struct aderived;
struct aderived2;
struct abase{
abase() : pblc(0), prtd(0), prvt(0){}
public:
int pblc;
protected:
int prtd;
private:
int prvt;
friend void frb(abase *pb, aderived *pd);
};
struct aderived : protected abase{
void fn(abase *pb,
According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.
Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-10 14:52 ---
Can you attach preprocessed source, if it is still reproduceable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-10
14:54 ---
Subject: Re: [4.4 Regression] __builtin_apply failures
Created an attachment (id=16639)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16639action=view)
--
--- Comment #12 from kargl at gcc dot gnu dot org 2008-11-10 15:01 ---
(In reply to comment #11)
(In reply to comment #10)
Admitted, it does not say SIZE = 8, because this value may be
compiler- and system-dependent (may also be 12 for gfortran on some
platforms), which is why
--- Comment #14 from uros at gcc dot gnu dot org 2008-11-10 12:22 ---
Subject: Bug 37807
Author: uros
Date: Mon Nov 10 12:20:55 2008
New Revision: 141737
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141737
Log:
Backport from mainline:
2008-11-10 Ralph Loader
--- Comment #8 from gunnar at greyhound-data dot com 2008-11-10 12:54
---
(In reply to comment #7)
(In reply to comment #4)
There are two causes where GCC generates unneeded TST instructions.
A) General arithmetic
lsr.l #1,D0
tst.l d0
jbne ...
This tst instruction
--- Comment #13 from uros at gcc dot gnu dot org 2008-11-10 10:45 ---
Subject: Bug 37807
Author: uros
Date: Mon Nov 10 10:43:35 2008
New Revision: 141734
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141734
Log:
PR middle-end/37807
PR middle-end/37809
*
--- Comment #4 from aph at gcc dot gnu dot org 2008-11-10 12:10 ---
Subject: Bug 33304
Author: aph
Date: Mon Nov 10 12:08:55 2008
New Revision: 141735
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141735
Log:
2008-11-10 Andrew Haley [EMAIL PROTECTED]
Backport from
--- Comment #8 from vmakarov at redhat dot com 2008-11-10 16:12 ---
H.J., thanks for finding the problem and reducing the test case.
The problem could be solved by using extended register coalescing. Now IRA
coalesces only move insns (-fira-coalesce). But unfortunately usage of
--- Comment #4 from nickc at redhat dot com 2008-11-10 16:22 ---
Created an attachment (id=16645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16645action=view)
Testcase for the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
--- Comment #5 from nickc at redhat dot com 2008-11-10 16:22 ---
Oops - almost forgot - the bug needs a testcase for the g++ testsuite, so I
have uploaded a patch to add that as well.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
--- Comment #5 from yacwroy at gmail dot com 2008-11-10 16:35 ---
*** Bug 38069 has been marked as a duplicate of this bug. ***
--
yacwroy at gmail dot com changed:
What|Removed |Added
--- Comment #1 from yacwroy at gmail dot com 2008-11-10 16:35 ---
*** This bug has been marked as a duplicate of 12255 ***
--
yacwroy at gmail dot com changed:
What|Removed |Added
According to the spec, you can't assign the value of a less-restrictive
function pointer to a more-restrictive function pointer.
Relevant C++ Spec section: 15.4 -3- (except.spec)
==
Code below taken directly from the C++ spec above.
--- Comment #11 from ubizjak at gmail dot com 2008-11-10 12:24 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-10 17:09
---
*** This bug has been marked as a duplicate of 38069 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-10 17:09
---
*** Bug 38071 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38069
This is similar to PR36817, but has different reasons.
% cat x.c
void fail (void)
{
unsigned int w[5], *wi;
wi = w[2];
do {
unsigned int x = wi[-2];
*wi = x;
} while (++wi w+5);
}
% ./gcc/cc1 -O3 -quiet x.c
x.c: In function #8216;fail#8217;:
x.c:2: internal compiler error:
--- Comment #10 from uros at gcc dot gnu dot org 2008-11-10 12:22 ---
Subject: Bug 37809
Author: uros
Date: Mon Nov 10 12:20:55 2008
New Revision: 141737
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141737
Log:
Backport from mainline:
2008-11-10 Ralph Loader
ICE on what I believe to be valid code. I've seen this happen on
all 4.3.x variants I've tired, but works fine with earlier versions gcc. The
error disappears when optimisation is not used. The following is the setup
I've used for the report:
'g++ -v' gives:
Using built-in specs. Target:
--- Comment #8 from jamborm at gcc dot gnu dot org 2008-11-10 10:06 ---
The previous patch resulted into a regression on m32c-unknown-elf and
thus I prepared a less intrusive one below. See also:
* http://gcc.gnu.org/ml/gcc/2008-11/msg00058.html and
*
--- Comment #1 from c dot galambos at omniperception dot com 2008-11-10
17:39 ---
Created an attachment (id=16646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16646action=view)
Preprocessor output .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-10 17:44 ---
Works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-10 17:46 ---
I think the problem is likely in the SCEV code again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-10 17:48 ---
It was ICEing in
0x002084ac in remap_ssa_name (name=0x18e9c40, id=0xb4cc) at
/Users/apinski/src/local/gcc/gcc/tree-inline.c:192
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I just had a look at some of the source code of the compiler
gcc version 4.4.0 snapshot 20081107.
$ egrep new|delete libstdc++-v3/config/locale/gnu/monetary_members.cc | fgrep
__wcs_ps
__wcs_ps = new wchar_t[__len];
delete __wcs_ps;
__wcs_ps = new
--- Comment #2 from nickc at redhat dot com 2008-11-10 13:36 ---
Created an attachment (id=16644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16644action=view)
Allow postfix parser to pass cp_id_kind information back to the primary parser
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from matz at gcc dot gnu dot org 2008-11-10 18:08 ---
Well, the invalid {LE,GT}_EXPRs trees are build right there in the patched
function, which is also the one that introduces the use of sizetype at all
(since the POINTER_PLUS_EXPR merge it seems, from 2007-06-15).
--
--- Comment #3 from rakdver at gcc dot gnu dot org 2008-11-10 18:32 ---
It might be that only number_of_iterations_lt_to_ne needs to be changed,
I looked at other uses of fold_build* in tree-ssa-loop-niter.c and quite
some others also look at least fishy (at least those generating
--- Comment #12 from uros at gcc dot gnu dot org 2008-11-10 09:09 ---
Subject: Bug 37807
Author: uros
Date: Mon Nov 10 09:08:15 2008
New Revision: 141732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141732
Log:
PR middle-end/37807
PR middle-end/37809
*
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org
--- Comment #7 from ams at gcc dot gnu dot org 2008-11-10 12:29 ---
(In reply to comment #4)
There are two causes where GCC generates unneeded TST instructions.
A) General arithmetic
lsr.l #1,D0
tst.l d0
jbne ...
This tst instruction is unneeded as the LSR is setting the
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-11-10 19:20 ---
Here is a better backtrace:
#0 remap_ssa_name (name=0xb7d3c000, id=0xbfda005c) at
/home/apinski/src/gcc-sony/gcc-4.3-clean/gcc/gcc/tree-inline.c:192
#1 0x08127db4 in copy_body_r (tp=0xb7d3dc28,
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-11-10 19:27 ---
Still happens on the 4.3 branch as of 4.3.3 20080918. Building a new compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
--- Comment #15 from ubizjak at gmail dot com 2008-11-10 12:24 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #9 from uros at gcc dot gnu dot org 2008-11-10 10:45 ---
Subject: Bug 37809
Author: uros
Date: Mon Nov 10 10:43:35 2008
New Revision: 141734
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141734
Log:
PR middle-end/37807
PR middle-end/37809
*
gcc -c -O3 -fgraphite-identity test_seg.c
test_seg.c: In function 'test_seg':
test_seg.c:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
GDB is giving following message
--- Comment #1 from mitul dot thakkar at amd dot com 2008-11-10 19:41
---
Created an attachment (id=16647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16647action=view)
Reduced Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38073
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from ams at gcc dot gnu dot org 2008-11-10 13:01 ---
This tst instruction is unneeded as the LSR is setting the flags correctly
already.
This is NOT correct. LSL does write to the condition codes, but not all of it.
In particular, the bit involved in the not-equal
With gfortran 4.3.2 the functions ddx and ddy in the channel.90 polyhedron test
with:
gfortran -S -m64 -O3 -ffast-math -finline-limit=312 channel.f90
but not for -finline-limit=311.
Since the IRA merge, this is no longer the case even if I use
-finline-limit=6000. This causes a ~5% increase in
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
When the below code (see How-To-Repeat) is compiled and run, the
program waits for input after initializing the Scanner. That input is
then returned to the first input.next() call, and each input.next()
call returns the user input given during the previous call.
Environment:
System: Linux
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38068
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-10 22:33 ---
*** This bug has been marked as a duplicate of 15795 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #39 from pinskia at gcc dot gnu dot org 2008-11-10 22:33
---
*** Bug 38063 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-11-10 22:39
---
(In reply to comment #10)
on arm I get
That is a target issue, please file it as a separate bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37433
In 32 bit mode the failure is:
/var/tmp//ccPCZsXJ.s:44:non-relocatable subtraction expression,
__ZN12_GLOBAL__N_11c1tE minus L001$pb
/var/tmp//ccPCZsXJ.s:44:symbol: __ZN12_GLOBAL__N_11c1tE can't be undefined in
a subtraction expression
In 64 bit mode, the failure is
Undefined symbols:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |target
Keywords||build,
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-11-10 23:11 ---
Subject: Bug 37514
Author: kkojima
Date: Mon Nov 10 23:10:10 2008
New Revision: 141752
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141752
Log:
PR rtl-optimization/37514
* config/sh/sh.h
--- Comment #9 from vmakarov at gcc dot gnu dot org 2008-11-10 23:23
---
Subject: Bug 37948
Author: vmakarov
Date: Mon Nov 10 23:21:45 2008
New Revision: 141753
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141753
Log:
2008-11-07 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-11-10 23:25 ---
Currently worked around with the patch in #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-10
23:52 ---
Subject: Re: [4.4 Regression] FAIL:
26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at
tree-cfg.c:3962
Can you attach preprocessed source, if it is still reproduceable?
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-10 23:57 ---
Confirmed, still fails today on 4.3 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl at gcc dot gnu dot org 2008-11-11 00:01 ---
Subject: Bug 37948
Author: hjl
Date: Mon Nov 10 23:59:57 2008
New Revision: 141756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141756
Log:
2008-11-10 H.J. Lu [EMAIL PROTECTED]
Backport from
--- Comment #2 from hjl at gcc dot gnu dot org 2008-11-11 00:03 ---
Subject: Bug 37397
Author: hjl
Date: Tue Nov 11 00:02:20 2008
New Revision: 141757
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141757
Log:
2008-11-10 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #19 from pinskia at gcc dot gnu dot org 2008-11-11 00:52
---
Blah, turning on/off strict aliasing via the option pragma would be a good
idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
--- Comment #10 from hp at gcc dot gnu dot org 2008-11-11 01:00 ---
Is this now a duplicate of PR37742, which according to the reporter still fails
for the original test-case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
When I was helping someone with a strict aliasing issue, I noticed that since
the fix for PR 37106, the option pragma cannot control strict aliasing. This
is not documented at all but I think it would be a good idea to be able to
control this option also.
--
Summary: strict aliasing
struct aderived;
struct aderived2;
struct abase{
abase() : pblc(0), prtd(0), prvt(0){}
public:
int pblc;
protected:
int prtd;
private:
int prvt;
friend void frb(abase *pb, aderived *pd);
};
struct aderived : protected abase{
void fn(abase *pb,
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-11 01:33 ---
*** Bug 38078 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38068
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-11 01:33 ---
*** This bug has been marked as a duplicate of 38068 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from anubhav dot saxena at wipro dot com 2008-11-11 01:48
---
(In reply to comment #1)
*** Bug 38078 has been marked as a duplicate of this bug. ***
I had only logged 38068. I am not sure how and why 38078 came into picture.
Also I am unable to figure out if this is
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-11 05:28
---
Closing, not a bug any more.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 06:00 ---
(In reply to comment #7)
Actually we can fold C - a == a only for odd C.
But more generally a +- b == a to b == 0.
right... that works as well for this optimization.
The original argument was on the range of a and
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-11
06:27 ---
(In reply to comment #3)
Patch at:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html
That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\otherg++
pr35504.C . Currently it fails
--- Comment #40 from David dot Monniaux at imag dot fr 2008-11-11 06:24
---
Yes, at least the manual should be updated to reflect this non-obvious
behavior.
Possible fixes for the programmer:
1) Overload operators new. new[] for a class wrapping the vector datatypes. It
works as long
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-11 06:49 ---
The current patch is at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
$ gcc -O3 -ftree-vectorizer-verbose=9 -c set_str.i
(lots of blah-blah)
set_str.c:326: note: get vectype with 4 units of type const unsigned char
set_str.c:326: note: vectype: const vector unsigned char
set_str.c:326: note: set_str.c: In function __gmpn_set_str:
set_str.c:54: internal compiler
--- Comment #1 from David dot Monniaux at imag dot fr 2008-11-11 07:00
---
Created an attachment (id=16649)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16649action=view)
gcc -c -O3 -ftree-vectorizer-verbose=9 set_str.i segfaults
This code comes from GNU MP 4.2.4.
--
--- Comment #124 from David dot Monniaux at imag dot fr 2008-11-11 07:46
---
Vincent Lefèvre is right: the issue is quite subtle. (I should mention that
Vincent is an expert in computer arithmetics, which I'm not.)
As he rightly points, conformance to IEEE-754 should be evaluated for
87 matches
Mail list logo
