--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:21 ---
This problem is also suppressed on i686-apple-darwin9 if I compile with...
gfortran -O3 -fno-PIC testcase.f
...since Darwin defaults to -fPIC, this may be why I wasn't seeing the failure
on Linux.
--
--- Comment #5 from dannysmith at users dot sourceforge dot net 2009-01-16
07:14 ---
(In reply to comment #4)
> I've just run into this problem too.
> In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
> chkstk.o and placed them whole into the import lib.
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:14 ---
I haven't had any luck reproducing this under Linux but since the problem is
suppressed by adding write statements it may be a bad memory access that only
darwin is triggering.
--
http://gcc.gnu.org/bu
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:12 ---
Created an attachment (id=17116)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17116&action=view)
diff of assembly from testcase.f under r143140 and r143152 on
i686-apple-darwin9
--
http://gcc.gn
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:11 ---
Created an attachment (id=17115)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17115&action=view)
assembly file from testcase.f under r143152 on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:10 ---
Created an attachment (id=17114)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17114&action=view)
assembly file from testcase.f under r143140 on i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:08 ---
The problem exists in r143152 but not r143140.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-01-16
07:07 ---
Created an attachment (id=17113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17113&action=view)
testcase extracted from xplor-nih
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
The change
Author: rguenth
Date: Wed Jan 7 10:53:30 2009
New Revision: 143152
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143152
Log:
2009-01-07 Richard Guenther
PR middle-end/38751
* fold-const.c (extract_muldiv): Remove obsolete comment.
(fold_plusminu
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed
--- Comment #9 from burnus at gcc dot gnu dot org 2009-01-16 06:50 ---
> Can we still get this into 4.4? In a way the ICE is a regression, since 4.3
> just gave an error message (stating that procedure pointers are not
> implemented) but no ICE.
I think one could; the patch only affects
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-16 06:41 ---
This bug was introduced by the fix for PR 10990.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38579
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-16 06:17 ---
Ah yes, I see. The bug is not with the visibility of the copy ctor, but with
the conversion from B to P in order to call it.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from jason at gcc dot gnu dot org 2009-01-16 06:08 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from jason at gcc dot gnu dot org 2009-01-16 06:08 ---
Subject: Bug 38850
Author: jason
Date: Fri Jan 16 06:08:20 2009
New Revision: 143424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143424
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tel
--- Comment #9 from jason at gcc dot gnu dot org 2009-01-16 06:08 ---
Subject: Bug 38850
Author: jason
Date: Fri Jan 16 06:08:09 2009
New Revision: 143423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143423
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tell
I'm compiling "gcc version 4.4.0 20090114 (experimental) [trunk revision
143401]" on "i386-pc-solaris2.11" (OpenSolaris 2008.11) and ./configured
using: --enable-gstreamer-peer
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-langua
--- Comment #6 from kargl at gcc dot gnu dot org 2009-01-16 05:26 ---
(In reply to comment #5)
> ifort (IFORT) 10.1 20080801
> Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
>
> $ ./a.out
> T F
>
> I want to get my head around this too. :)
Note, there are 2 separat
--- Comment #8 from jason at gcc dot gnu dot org 2009-01-16 05:04 ---
Subject: Bug 38850
Author: jason
Date: Fri Jan 16 05:04:26 2009
New Revision: 143422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143422
Log:
PR c++/38850
* pt.c (tsubst_copy_and_build): Tell
--- Comment #7 from jason at gcc dot gnu dot org 2009-01-16 04:55 ---
4.2 and 4.3 handle this fine, I don't know why it was marked as a 4.2/4.3
regression.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jason at gcc dot gnu dot org 2009-01-16 04:54 ---
Actually, this is still an accepts-invalid bug when weird is uncommented.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jason at gcc dot gnu dot org 2009-01-16 03:50 ---
11.4: A name nominated by a friend declaration shall be accessible in the scope
of the class containing the friend declaration.
Confirmed.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-01-16 02:57
---
ifort (IFORT) 10.1 20080801
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
$ ./a.out
T F
I want to get my head around this too. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-16 02:47 ---
I think I know how to fix this. I'll note that James' clever
programs may be invoking processor defined behavior due to
the multiplication by 0 in his specification statements.
See 7.1.8.1.
--
http://gcc.gnu.org/
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 02:33 ---
Mine. Simple patch which implements it in vn_reference_lookup, Since VCE is
both a reference and really a bit-wise cast, we can do the normal lookup and
then do a lookup if the VCE was not there. I have not seen if
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-01-16 02:26 ---
Created an attachment (id=17112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17112&action=view)
add in stubs.c for long double only
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
--- Comment #13 from bkoz at gcc dot gnu dot org 2009-01-16 02:26 ---
Ouch. I see this also on arm-elf crosses, whoops.
Here's a patch that I'm currently testing on cross. If it fixes it, then I'll
check it in and then please try on hpux.
--
bkoz at gcc dot gnu dot org changed:
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-01-16 02:11 ---
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 143415)
+++ tree-ssa-forwprop.c (working copy)
@@ -775,29 +775,43 @@ forward_propagate_
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-16 02:01 ---
So the problem here is that we should not forward prop *(struct a*)&f into an
expression which is taking the address ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-16 00:55 ---
(In reply to comment #2)
> Before closing, please also check the two longer cases:
> http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
> and the older (partially incorrect?) one at
> http://groups.g
--- Comment #13 from kargl at gcc dot gnu dot org 2009-01-16 00:40 ---
I have a patch for this problem. I'll clean it up on Saturday and
submit it.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
00:24 ---
Subject: Re: FAIL: abi_check
> --- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-13 10:02 ---
> Created an attachment (id=17084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17084&ac
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-15 23:57 ---
Revision 121570 is:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00319.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38844
--- Comment #8 from sje at cup dot hp dot com 2009-01-15 23:45 ---
Fixed with change to test.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-15
23:40 ---
Subject: Re: FAIL: gcc.dg/builtins-20.c (test for excess errors)
> I think we can close it. Any objections?
No.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-15 23:40 ---
Note with the disabling of VCE creation for *(float*)&sv->i after this bug has
been fixed, there is a possibility that -O2 -fno-strict-aliasing could get
slightly better code than -O2 :).
--
pinskia at gcc dot gn
Take:
struct s { int i; };
float a (struct s *sv)
{
sv->i = 0;
int d = sv->i;
return *(float*)&d;
}
float a1 (struct s *sv)
{
sv->i = 0;
return *(float*)&sv->i;
}
We miss that we could constant prop 0 into the VIEW_CONVERT_EXPR.
Likewise for non aliasing issues but with vectors:
#defin
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-15 23:30 ---
PR 38747 has the best patch which allows most optimizations still but only
disabling it for the invalid cases when the aliasing sets are not equal.
Take:
struct S { unsigned f; };
int __attribute__((noinline))
foo (
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-15 23:26 ---
Created an attachment (id=17111)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17111&action=view)
Patch which should fix this and PR 38748
This patch still creates VCE for INDIRECT_REF based but only if the al
--- Comment #13 from sje at cup dot hp dot com 2009-01-15 23:23 ---
It looks like the test was changed to fix this failure. Marking as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-15 23:16 ---
The CSE of the load is only valid at -O2 and above (strict aliasing turned on).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-15 23:12 ---
3.4.2 begins "When an unqualified name is used as the postfix-expression in a
function call" The call func(x) does not get argument-dependent
lookup because func is not an unqualified name, it's a template-id. Th
--- Comment #7 from sje at cup dot hp dot com 2009-01-15 23:09 ---
I think this should be closed as WONTFIX. There may or may not be a 3.3.6 GCC
bug that was causing a bootstrap failure but it isn't going to be fixed so we
may as well close this defect. If anyone objects they can reope
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-15 23:07 ---
7.3.1.2: If a friend declaration in a non-local class first declares a class or
function the friend class or function is a member of the innermost enclosing
namespace. The name of the friend is not found by unqualified
--- Comment #32 from sje at cup dot hp dot com 2009-01-15 23:03 ---
*** Bug 30183 has been marked as a duplicate of this bug. ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2009-01-15 23:03 ---
I agree that this is a duplicate of pr29478 so I am going to close it as such.
*** This bug has been marked as a duplicate of 29478 ***
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-15 22:58 ---
That's not enough, as the typedef names also changed :(.
So, for npupp.h:
NewNPP_XXXProc (YYY)
or
(NPP_XXXUPP) (YYY)
works, for npfunctions.h:
(NPP_XXXProcPtr) (YYY)
And, jref isn't typedefed for new xulrunner (but th
--- Comment #6 from sje at cup dot hp dot com 2009-01-15 22:58 ---
It looks like this test is passing since the test was changed to include
the #ifdef HAVE_C99_RUNTIME. It looks OK on the 4.3 branch and trunk so
I think we can close it. Any objections?
--
sje at cup dot hp dot com
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-15 22:57 ---
Fixed for 4.3 and 4.4, not fixing for 4.2.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-15 22:56 ---
Fixed for 4.3 and 4.4. Not fixing for 4.2.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from janus at gcc dot gnu dot org 2009-01-15 22:56 ---
Created an attachment (id=17110)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17110&action=view)
patch
Here is a patch which fixes the testcases in comment #0, #1 and #7.
Dominique: Maybe you could check wheth
--- Comment #15 from jason at gcc dot gnu dot org 2009-01-15 22:54 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from hjl dot tools at gmail dot com 2009-01-15 22:38 ---
This patch:
--- ./ipa-inline.c.foo 2009-01-02 11:06:18.0 -0800
+++ ./ipa-inline.c 2009-01-15 14:35:28.0 -0800
@@ -1412,7 +1412,8 @@ cgraph_decide_inlining_incrementally (st
}
--- Comment #14 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 31488
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lval
--- Comment #5 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 36334
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalu
--- Comment #3 from jason at gcc dot gnu dot org 2009-01-15 22:34 ---
Subject: Bug 37646
Author: jason
Date: Thu Jan 15 22:34:20 2009
New Revision: 143413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143413
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalu
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-15 22:16
---
>Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log :
No, it is not broken at all. __sync_val_compare_and_swap_4 cannot be used with
x86 explicit -march=i686 is used as the default really is to compile for
--- Comment #4 from sje at cup dot hp dot com 2009-01-15 22:16 ---
Bug was fixed before 4.3.0 was released. Closing as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
---
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-15
22:14 ---
Subject: Re: FAIL: gcc.misc-tests/gcov-2.c ICE
> --- Comment #2 from sje at cup dot hp dot com 2009-01-15 22:09 ---
> David, can we close this out? I don't see the failure with 4.3.0 or on ToT.
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-15 22:11
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
LAST_UPDATED: Fri Jan 9 01:21:29 UTC 2009 (revision 143198)
$ ../trunk/configure --with-arch=native --disable-java-awt --without-x
--enable-__cxa_atexit --disable-libgomp --disable-static
--enable-languages=c,c++,java --disable-fixed-point --enable-checking=release
--with-gmp=/home/daney/mp --wit
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-01-15 22:10
---
Subject: Bug 29388
Author: pinskia
Date: Thu Jan 15 22:10:24 2009
New Revision: 143411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143411
Log:
2009-01-15 Andrew Pinski
PR C++/29388
--- Comment #2 from sje at cup dot hp dot com 2009-01-15 22:09 ---
David, can we close this out? I don't see the failure with 4.3.0 or on ToT.
I am guessing this was fixed with the following change to pa.c:
r123
--- Comment #9 from rob1weld at aol dot com 2009-01-15 22:03 ---
(In reply to comment #4)
> Hmm, automake should have done the correct thing ...
(In reply to comment #5)
> # Even if the default multilib is not a cross compilation,
> # it may be that some of the other multilibs are.
> if
--- Comment #4 from dcb314 at hotmail dot com 2009-01-15 21:51 ---
(In reply to comment #3)
> An updated patch is at
>
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00747.html
I have a couple of minor questions about the coding style
of this patch.
1. Why is the "/ 8 / 8" a good idea
The following program gives the wrong answers from the WHERE block. The
expected answers are in the tda2l array. The problem seems to be an
interaction between the dimension statements, the defined logical assignment
and the defined integer assignment statement in the WHERE block.
The defined
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-15 21:35 ---
It is caused by revision 121570:
http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00126.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-15 21:30 ---
quick fix:
Index: simplify.c
===
--- simplify.c (révision 143354)
+++ simplify.c (copie de travail)
@@ -2253,7 +2253,8 @@ simplify_bound (gfc_expr *ar
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-15
21:18 ---
Created an attachment (id=17109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109&action=view)
Order BACKENDLIBS by dependencies.
I'd consider this fix obvious. Verified that it resolves the li
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-15 21:17 ---
Here is a good testcase:
void
VecADD(
int *In1,
int *In2,
int *Out,
unsigned int samples
){
int i;
for (i = 0; i < samples; i++) {
Out[i] = In1[i];
}
}
This testcase should be vectorized wi
[ ref: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00179, full details of
configuration etc. ]
In gcc/Makefile.in, the current definition of BACKENDLIBS says:
BACKENDLIBS = $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS)
This is incorrect WRT dependency order. Cloog and PPL depend on GMP/MPFR, and
so s
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-15 21:13 ---
This bug is a bit funny, autoincrement is not the issue, just the detecting of
the induction variable's limits correctly. For an example I noticed that if I
compile this on a LP64 target, the induction variable is f
--- Comment #2 from sergei_lus at yahoo dot com 2009-01-15 21:03 ---
Andrew, thank you for the prompt reply.
I have seen PR 31849 and used the patch suggested. Without it autoincrement
would not work at all for either case. But the patch seems to deal with the
case when iv _were_ detec
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-15 20:48
---
Yeah, this is simply because we are implementing the resolution of DR596:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596
This is documented, both in the source code and in the docs.
--
https://bugzilla.mozilla.org/show_bug.cgi?id=455458
xulrunner helpfully renamed npupp.h that gcjwebplugin.cc uses to npfunctions.h
and removed all the NewNPP_* macros (and jref is gone as well).
I'm trying now:
--- libjava/classpath/native/plugin/gcjwebplugin.cc.jj 2009-01-14
12:08:34.0
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-15 20:10 ---
ida = lbound(a%i)
if (any(ida /= (/1,1/))) print *, 'lbound', ida
Here, gfortran prints:
lbound 0 2
Correct would be
lbound 1 1
ida = ubound(a)
>>>^^^
Here a "%i"
--- Comment #1 from aczapran at hotmail dot com 2009-01-15 20:09 ---
Created an attachment (id=17108)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17108&action=view)
preprocessed file attaced = "a.ii"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38860
C++ pgm attempts to verify rdstate of an ofstream opened as follows:
...
ostr.open(tn, std::ios_base::out | std::ios_base::in | std::ios_base::app);
if(ostr.rdstate() == std::ios_base::failbit)
printf( "good\n");
else
printf( "bad.. should be failbit\n" );
...
gcc version info
--
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-15 20:04 ---
Confirm. This is a regression with regards to 4.2.1; it fails at least since
20071008 (my oldest 4.3 trunk version).
Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from bkoz at gcc dot gnu dot org 2009-01-15 20:02 ---
Subject: Bug 32666
Author: bkoz
Date: Thu Jan 15 20:02:11 2009
New Revision: 143406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143406
Log:
2009-01-15 Benjamin Kosnik
PR libstdc++/32666
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-15 19:58 ---
This is the patch which fixes the issue:Index: regrename.c
===
--- regrename.c (revision 3023)
+++ regrename.c (working copy)
@@ -1374,6 +1374,10 @@ may
The UBOUND and LBOUND intrinsics treat a reference to an array structure
component as if they were inquires on a whole array.
Dick Hendrickson
program try_jg_15_18
! fails on Windows XP
! gcc version 4.4.0 20081219 (experimental) [trunk revision 142842] (GCC)
type x
in
--- Comment #4 from raksit at google dot com 2009-01-15 19:32 ---
Yes, this looks like the same problem as in PR 23449.
The benchmarks runs fine if I compile with "-O2 -fno-strict-aliasing". And I
see from PR 23449 that this is a source-code issue. Closing this as a
duplicate.
*** This
--- Comment #4 from raksit at google dot com 2009-01-15 19:32 ---
*** Bug 38858 has been marked as a duplicate of this bug. ***
--
raksit at google dot com changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-15 19:30 ---
Can you try -O2 -fno-strict-aliasing. If that works, then this is a dup of bug
23449 :). bug 23449 has a nice explication of where and how vortex violates
C/C++ aliasing rules.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from raksit at google dot com 2009-01-15 19:27 ---
I am compiling vortex with "-O2" (it builds and runs correctly with -O0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38858
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-15 19:25 ---
Last time I looked into vortex, it had some aliasing issues, see PR 23449.
What options are you compiling vortex with?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
The 4.4 trunk gcc (I have tried revisions 143386, 143405) builds this SPEC2000
benchmark fine. But on running this benchmark, it segfaults pretty much
immediately (using any of the test, train, or ref inputs).
--
Summary: 255.vortex benchmark segfaults
Product: gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
With this test case the selective scheduler is hitting a gcc_assert in
sel-sched-ir.c I see this on IA64 Linux or on IA64 HP-UX when in 64 bit mode.
In both cases it happens when compiling with -O3.
x.c: In function 'dv_guess_qnos':
x.c:22: internal compiler error: in sel_move_insn, at sel-sche
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-15 18:41 ---
Well first off, iv-opts on the tree level should be the place where
autoincrement is helped out. See PR 31849 which I think this is a duplicate
of.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15
19:08 ---
I've just run into this problem too.
In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib. I'm not sure why he didn't
do th
--- Comment #10 from doko at ubuntu dot com 2009-01-15 18:38 ---
checked the patch with trunk 20090115:
=== libstdc++ tests ===
Running target unix
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
=== libstdc
--- Comment #4 from syntheticpp at gmx dot net 2009-01-15 18:56 ---
It has nothing to do with templates.
This code still compiles:
struct P
{
protected:
P() {}
P(const P&) {}
};
struct B : protected P
{
B() {}
};
struct C : public P
{
C(const B& b) : P(b) {}
};
void
I apologize if it is a well disguised feature, but I am forced to consider this
being a performance regression/bug.
In the following trivial example:
void
VecADD(
long long *In1,
long long *In2,
long long *Out,
unsigned int samples
){
int i;
for (i = 0; i < samples; i++) {
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-15 18:14 ---
Subject: Bug 37646
Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalu
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-15 18:14 ---
Subject: Bug 36334
Author: jason
Date: Thu Jan 15 18:14:32 2009
New Revision: 143404
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c (lvalu
--- Comment #3 from sje at gcc dot gnu dot org 2009-01-15 18:09 ---
Subject: Bug 38357
Author: sje
Date: Thu Jan 15 18:09:04 2009
New Revision: 143403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143403
Log:
PR c++/38357
* g++.dg/template/crash87.C: New test.
1 - 100 of 152 matches
Mail list logo
