--- Comment #2 from bje at gcc dot gnu dot org 2009-04-09 06:17 ---
Reproduced.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|
--- Comment #23 from charlet at gcc dot gnu dot org 2009-04-09 06:37
---
Certainly, pa-hpux and ia64-hpux are two very different platforms as far as
GCC is concerned.
Also, yes, FSF GCC and GNAT Pro are two very different beasts with a different
list of supported/tested platforms,
--- Comment #28 from rguenther at suse dot de 2009-04-09 07:58 ---
Subject: Re: C++ empty struct is passed incorrectly
On Wed, 8 Apr 2009, hjl dot tools at gmail dot com wrote:
--- Comment #23 from hjl dot tools at gmail dot com 2009-04-08 23:41
---
This looks like an
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2009-04-09 08:07
---
Would that be what we refer to as hpux-ia64 ?
No, IA-64 and PA-RISC are different things.
GNAT Pro is the natural Ada solution for HPs Alpha server and Integrity
server (I64) platforms or is gcc's Ada not
In the Fortran95 standard, section 5.1, one finds:
Constraint: If the POINTER attribute is specified, the TARGET, INTENT,
EXTERNAL, or INTRINSIC attribute shall not be specified.
Thus, the following should be rejected with -std=f95:
external f
pointer f
And consequently also something like
--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-09 08:39 ---
After removing the comment in the line
! f = sin
I get on powerpc-apple-darwin9, revision 145779:
[karma] f90/bug% gfc pr39692.f90
pr39692.f90:3.11:
external f
1
Error: EXTERNAL attribute conflicts
Hi,
there are lots of bugs concerning the issue that uninitialized local variable
uses are not always reported. See 10539 or 19099.
I think the restriction to optimized builds is particularly unfortunate, since
a dev is more likely to actually look at a debug build. I'm not everybody, but
--- Comment #11 from bonzini at gnu dot org 2009-04-09 10:34 ---
*** Bug 35655 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2009-04-09 10:34 ---
*** This bug has been marked as a duplicate of 32431 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #9 from sylvain dot pion at sophia dot inria dot fr 2009-04-09
10:06 ---
There seems to have been some progress : it now takes 6000-9000 cycles instead
of 2.
This is 6000 with g++ 4.3.1 on a Fedora 10 x86_64 box, and 9000 on a MacBook
Pro with various g++ versions up
--- Comment #12 from ramana at gcc dot gnu dot org 2009-04-09 11:31 ---
For the record here's some more info on the problem.
One part of the problem is as described in comment #1 about labels having the
right bit and the correct instruction being generated which I've achieved by a
on mingw target i can't get libgcc_s.a path.
the path to libgcc.a is returned correctly:
$ i686-pc-mingw32-gcc -print-file-name=libgcc.a
/local/devel/toolchain44/i686-pc-mingw32.host64/lib/gcc/i686-pc-mingw32/4.4.0/libgcc.a
but the libgcc_s.a case doesn't work. it returns:
$
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-09 12:08 ---
The bugs you mention are fixed.
In GCC 4.4, some uninitialized uses are reported even at -O0. If you have
specific testcases not covered by any PR linked in bug 24639, then open a new
PR and attach the preprocessed
--- Comment #4 from bonzini at gnu dot org 2009-04-09 10:36 ---
seems to be fixed on trunk.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2009-04-09 09:41 ---
Fixed by r145815. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janus at gcc dot gnu dot org 2009-04-09 09:39 ---
Subject: Bug 36704
Author: janus
Date: Thu Apr 9 09:39:09 2009
New Revision: 145815
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145815
Log:
2009-04-09 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #3 from MR dot Swami dot Reddy at nsc dot com 2009-04-09 11:00
---
This issue is not reproduced with gcc-4.3.3 sources (ie released sources).
Only obsereved with gcc-4.5.0 trunk sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
--- Comment #16 from bonzini at gnu dot org 2009-04-09 11:00 ---
On i686 to spu cross, for -O2 45 minutes were not enough.
--
bonzini at gnu dot org changed:
What|Removed |Added
For procedure pointer results without an explicit RESULT statement, error
messages may contain the wrong name (since a hidden result variable named
'ppr@' is added).
Examples:
function f()
pointer :: f
interface
integer function f(x) bind(c) ! may not be a C interoperable kind
On Linux/ia32, I got
FAIL: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump ccp1 a\[D\.
FAIL: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump forwprop1 = a\[D\.
--
Summary: gcc.dg/tree-ssa/ssa-ccp-25.c scan-tree-dump doesn't work
on Linux/ia32
Product: gcc
--- Comment #2 from simon dot thum at gmx dot de 2009-04-09 13:11 ---
Sorry for the noise; I didn't check the developer docs (just latest release)...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693
--- Comment #3 from simon dot thum at gmx dot de 2009-04-09 13:15 ---
BTW in developer docs, -Wextra still mentions -Wuninitialized; it seems to me
this is not intentional.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39693
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 13:24 ---
Confirmed. [-Weffc++ is basically unmaintained though]
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2009-04-09 13:25 ---
(In reply to comment #3)
BTW in developer docs, -Wextra still mentions -Wuninitialized; it seems to me
this is not intentional.
Both -Wall and -Wextra enable Wuninitialized. I guess this is historical.
Please,
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 13:32 ---
Interesting. On 64bit we gimplify to
p = a[0];
D.1596 = (long unsigned int) i;
D.1597 = D.1596 * 4;
D.1598 = p + D.1597;
while on 32bit we get
p = a[0];
i.0 = (unsigned int) i;
D.1253 = i.0 * 4;
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-09 13:37 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-09 13:37 ---
Subject: Bug 39696
Author: rguenth
Date: Thu Apr 9 13:36:57 2009
New Revision: 145839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145839
Log:
2009-04-09 Richard Guenther rguent...@suse.de
PR
147] uname -a
FreeBSD fbsd.lokal.biz 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Aug 4 14:54:03
CEST 2008 r...@fbsd.lokal.biz:/usr/src/sys/i386/compile/BSD70EV i386
148]
148] gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread
--- Comment #31 from dave at boost-consulting dot com 2009-04-09 13:58
---
OK, I don't get what it's controlling then, but maybe that's not important.
Still, I suggest you choose a more specific name to leave the door open for
prettier template printing in the future. If you did
--- Comment #29 from hjl dot tools at gmail dot com 2009-04-09 14:17
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00700.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
On x86_64 for gcc.dg/vect/pr34591.c I see with type checking enabled
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/vect/pr34591.c:3: error:
Incompatible types in PHI argument 1
vector int
vector short int
vect_var_.49_81 = PHI vect_var_.49_82(10), { 0, 0, 0, 0, 0, 0, 0, 0 }(4)
which is
--- Comment #1 from dodji at gcc dot gnu dot org 2009-04-09 14:59 ---
Confirmed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from sje at cup dot hp dot com 2009-04-09 14:59 ---
The proposed patch fixed my failures on IA64-hp-hpux11.23.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
--- Comment #30 from diepen at astron dot nl 2009-04-09 15:08 ---
I'm glad that the time I invested in writing the rather extensive test program
for the casacore ArrayMath pays off, although I had not expected to find this
problem.
Luckily it was not too hard to write a workaround in my
--- Comment #25 from rob1weld at aol dot com 2009-04-09 15:16 ---
That is good news, (that hppa2.0w-hp-hpux11.11 (PA-RISC 2.0.), which we
claim is supported, is not the same/similar to hpux-ia64, which has two
ZCX = False entries). We don't want to break that. Nice machine.
Is the
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 15:24 ---
Fixed in 4.2.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #26 from charlet at gcc dot gnu dot org 2009-04-09 15:40
---
Is the (small amount of ?) code in Gnat Pro going to be available
(someday) for gcc Ada. That may fix these problems.
There's still confusion I'm afraid. GCC Ada is just an Ada compiler.
GNAT Pro is a complete
--- Comment #6 from hjl at gcc dot gnu dot org 2009-04-09 15:44 ---
Subject: Bug 10039
Author: hjl
Date: Thu Apr 9 15:44:05 2009
New Revision: 145842
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145842
Log:
2009-04-09 H.J. Lu hongjiu...@intel.com
PR gas/10039
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-04-09 15:46
---
Non-regressions should not have a target milestone until they are fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-04-09 16:03 ---
(In reply to comment #4)
This of cause fails if you change i. As the program is invalid and as I don't
see any possibility to fix this in gfortran, I regard the problem of comment 3
as INVALID/WONTFIX.
In the
--- Comment #25 from jason at gcc dot gnu dot org 2009-04-09 16:05 ---
The C++ front end bit of this needs 22488 to be fixed before we can remove the
explicit call to the builtin and go back to using a MODIFY_EXPR. But in the
meantime we can test for pointer equality before the call.
Hello, no error reporting when function and variable have the same name in
class.
Please do this check and show this error.
--
Summary: No error reporting when function and variable have the
same name
Product: gcc
Version: 4.3.4
--- Comment #14 from janis at gcc dot gnu dot org 2009-04-09 17:01 ---
Subject: Bug 36610
Author: janis
Date: Thu Apr 9 17:00:57 2009
New Revision: 145850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145850
Log:
PR libobjc/36610
* objc/execute/forward-1.x: New.
The testcase of PR30668 is miscompiled with -fwhole-file:
$ gfortran-svn -Wall -W pr30668.f90 ./a.out
2.000 4
$ gfortran-svn -Wall -W pr30668.f90 -fwhole-file ./a.out
0.000 4
Expected output for the latter:
2.000...8
The dump shows
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 17:15 ---
Actually this code is invalid as explained by that PR :).
So just marking this as a dup of bug 30668. The whole issue is that the
front-end should be rejecting the code before it gets to the middle-end.
*** This
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-09 17:15 ---
*** Bug 39700 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from janis at gcc dot gnu dot org 2009-04-09 16:58 ---
Subject: Bug 36610
Author: janis
Date: Thu Apr 9 16:58:34 2009
New Revision: 145849
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145849
Log:
PR libobjc/36610
* objc/execute/forward-1.x: New.
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-09 17:34 ---
OMG! I was so puzzled with the results, I didn't read to the end of the
original PR :(
However, if the function TWO is declared INTEGER, the outcome is even worse,
even if -Wconversion is specified. So, there
--- Comment #10 from jb at gcc dot gnu dot org 2009-04-09 17:44 ---
Subject: Bug 39665
Author: jb
Date: Thu Apr 9 17:44:23 2009
New Revision: 145852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145852
Log:
2009-04-09 Janne Blomqvist j...@gcc.gnu.org
PR fortran/39665
On Linux/ia32, revision 145849 gives:
FAIL: g++.dg/tree-ssa/pr31146-2.C scan-tree-dump forwprop1 Replaced .* != 0B.
with .1
FAIL: gcc.dg/pr36901-1.c (test for excess errors)
FAIL: gcc.dg/pr36901-2.c (test for excess errors)
FAIL: gcc.dg/pr36901-3.c (test for excess errors)
FAIL:
--- Comment #6 from jason at gcc dot gnu dot org 2009-04-09 20:29 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #51 from jason at gcc dot gnu dot org 2009-04-09 20:30 ---
Patch applied for 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
On Linux/ia64, revision 145853 gave
default_format_(9000): unaligned access to 0x6fff8338,
ip=0x201cc370
default_format_(9000): unaligned access to 0x6fff8338,
ip=0x201cc370
default_format_(9000): unaligned access to 0x6fff8338,
ip=0x201cc370
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-09 20:58 ---
It is caused by revision 145852:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00476.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-09 21:00 ---
I took it back. The unaligned access started on Apr. 5 and revision
145852 doesn't fix them.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-09 21:08 ---
Subject: Bug 29200
Author: ayers
Date: Thu Apr 9 21:08:18 2009
New Revision: 145857
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145857
Log:
gcc/
2009-04-09 David Ayers ay...@fsfe.org
PR
--- Comment #3 from jb at gcc dot gnu dot org 2009-04-09 21:14 ---
HJ,
can you check if the patch at
http://gcc.gnu.org/ml/fortran/2009-04/msg00103.html
fixes your problems? It is the alternative way of solving the problem that IMHO
was not as clean as r145852, but if that one
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-09 21:15 ---
Fixed in 4.5.
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-09 21:17 ---
We need a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-09 21:19 ---
Subject: Bug 39613
Author: hjl
Date: Thu Apr 9 21:19:29 2009
New Revision: 145858
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145858
Log:
2009-04-09 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #7 from hjl at gcc dot gnu dot org 2009-04-09 21:19 ---
Subject: Bug 39614
Author: hjl
Date: Thu Apr 9 21:19:29 2009
New Revision: 145858
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145858
Log:
2009-04-09 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #8 from hjl at gcc dot gnu dot org 2009-04-09 21:19 ---
Subject: Bug 39673
Author: hjl
Date: Thu Apr 9 21:19:29 2009
New Revision: 145858
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145858
Log:
2009-04-09 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-04-09 21:25
---
Did the 145852 fix Steve's original problems or are they the same as HJ reports
here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702
--- Comment #2 from bje at gcc dot gnu dot org 2009-04-09 21:26 ---
Subject: Bug 36800
Author: bje
Date: Thu Apr 9 21:26:44 2009
New Revision: 145859
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145859
Log:
PR target/36800
PR target/36800
*
In generating DWARF debugging information, GCC produces a single location for
some formal parameters instead of a location list. This location is not valid
until the function prologue copies the parameter from the location where it
exists at function entry into the assigned location. A debugger
--- Comment #3 from bje at gcc dot gnu dot org 2009-04-09 21:29 ---
Should this be backported to 4.4?g
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 21:33 ---
IIRC at -O0, variable tracking is not enabled so it only produces single
locations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39703
Revision 145841 breaks bootstrap on powerpc-apple-darwin9:
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-09 21:48 ---
Simple typo:
* http://www.gnu.org/licenses/. */
*/
Just either remove */ and it will work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-09 22:00 ---
Subject: Re: [4.5 Regression] Revision 145841 breaks
bootstrap on powerpc-apple-darwin9
Just either remove */ and it will work.
Thanks. This is exactly what I am trying.
However someone will have to fix it in
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-09 22:21 ---
The following patch fixes this pr:
--- ../_gcc_clean/gcc/config/rs6000/darwin-vecsave.asm 2009-04-09
18:06:26.0 +0200
+++ ../gcc-4.5-work/gcc/config/rs6000/darwin-vecsave.asm2009-04-09
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-09 22:50 ---
Revision 145846:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00470.html
is the cause. I got
/export/gnu/import/rrs/145846/src/gcc/testsuite/gfortran.dg/alloc_comp_basics_2.f90:7:
internal compiler error:
--- Comment #32 from hjl at gcc dot gnu dot org 2009-04-09 22:59 ---
Subject: Bug 39678
Author: hjl
Date: Thu Apr 9 22:58:51 2009
New Revision: 145865
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145865
Log:
gcc/
2009-04-09 H.J. Lu hongjiu...@intel.com
PR
--- Comment #15 from paolo at gcc dot gnu dot org 2009-04-09 23:37 ---
Subject: Bug 39629
Author: paolo
Date: Thu Apr 9 23:37:08 2009
New Revision: 145867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145867
Log:
2009-04-09 Paolo Carlini paolo.carl...@oracle.com
PR
enum constants don't appear in .debug_pubnames.
It seems like perhaps they should, because they are global (in a sense).
--
Summary: enum constants don't appear in debug_pubnames
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity:
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-09 23:47
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Compile this with -g:
namespace x { int x; }
class y { public: static int x; };
int y::x;
int main() { return x::x; }
Now examine the debug_pubnames section with readelf. I see:
70 main
119 x
130 y::x
However, I expected x::x; y::x
gcc does not emit debug_pubtypes, except on Darwin.
It seems like it ought to do this unconditionally,
given that it is part of dwarf.
--
Summary: gcc does not emit debug_pubtypes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity:
In response to a request like break function, gdb will currently
search all objfiles for function -- and the request will succeed
even if function is private.
This means that gdb cannot start using the debug_pubnames index without
also exhibiting different behavior.
So, it might be nice to have
opts.c has
/* What to print when a switch has no documentation. */
#ifdef ENABLE_CHECKING
static const char undocumented_msg[] = N_(This switch lacks documentation);
#else
static const char undocumented_msg[] = ;
#endif
When gcc is configured with --enable-checking=assert, gcc
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-04-10 01:49
---
This issue is still being worked on 39702, no need for new bug report
*** This bug has been marked as a duplicate of 39702 ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-04-10 01:49
---
*** Bug 39709 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702
--- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
04:47 ---
class toto
{
enum e {a,b};
e test_example();
e test_example;
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
--- Comment #8 from abhinav dot dubey at hcl dot in 2009-04-10 05:29
---
I changed the compiler and its works.. thanks a lot for your advice
--
abhinav dot dubey at hcl dot in changed:
What|Removed |Added
85 matches
Mail list logo
