On 15 Jan 2009, at 01:44, Ian Lance Taylor wrote:
I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is
language dependent (on objc/objcxx).
It's pretty hard to think of any reason why something as low-level as
ASM_OUTPUT_LABEL_REF would want to look at anything in the frontend.
Ben Elliston wrote:
I cannot find where to download gcc binary for Linux. Can you email me
the link? It's so confusing in the http://gcc.gnu.org/ web site.
You should install gcc from your Linux distribution. It will be far
easier.
To add: There are no binaries of GCC released by the GCC
IainS develo...@sandoe-acoustics.co.uk writes:
2/ assume that no sensible user will make an intention external symbol
named ZL_OBJC_xx
perhaps that's not too unreasonable... OBJC_x are effectively
reserved identifiers - so perhaps mangled file scope variants of those
could be
hi,
I am trying to output automata description by using -v flag , but it failed.
The option parsing code seems have a little bug?
It parse extra flags in initiate_automaton_gen, after init_md_reader_args.
9327 if (init_md_reader_args (argc, argv) != SUCCESS_EXIT_CODE)
9328return
Tobias Burnus wrote:
Otherwise, you could consider building GCC yourself, cf.
http://gcc.gnu.org/install/. (Furthermore, some gfortran developers
offer regular GCC builds, which are linked at
http://gcc.gnu.org/wiki/GFortranBinaries; those are all unofficial
builds, come without any
Hi,
it seems that there's no trivial.m in gcc/testsuite/objc/execute
a copy of that in gcc/testsuite/objc/execute/exceptions would work
Iain.
#import objc/Object.h
int main(void)
{
[Object class];
return 0;
}
On Thu, Jan 15, 2009 at 12:13 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
Hi,
it seems that there's no trivial.m in gcc/testsuite/objc/execute
Hmm, this is only needed if execute.exp is run only I think.
Thanks,
Andrew Pinski
On 15 Jan 2009, at 20:40, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:13 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
Hi,
it seems that there's no trivial.m in gcc/testsuite/objc/execute
Hmm, this is only needed if execute.exp is run only I think.
that's true, and generally it's
On Thu, Jan 15, 2009 at 12:51 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
This doesn't seem quite right - because you get different results for
--target_board=unix\{-m32,-m64\} and --target_board=unix\{-m64,-m32\}
You should not get different results with those options. At least on
any
On 15 Jan 2009, at 20:57, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:51 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
This doesn't seem quite right - because you get different results for
--target_board=unix\{-m32,-m64\} and --target_board=unix\{-
m64,-m32\}
You should not get
Dave Korn wrote:
Sebastian Pop wrote:
Hi Seb,
Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
patches for the first two bugs if desired,
I would highly appreciate this.
Righto, will get cracking.
You already posted a patch for the first one and got
Snapshot gcc-4.3-20090115 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090115/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Now I just set v_flag to 1 manually in code to get the output, but I
don't think it is a correct way.
Anyone could tell me the correct way to output automata description,
or help me to confirm this bug?
I don't think there is a bug. What do you have in your define_automaton
directive? Note
struct s
{
char a:4;
char b:8;
char c:4;
} __attribute__ ((packed))
is 3 bytes long because b gets pushed to the next byte boundary.
You would think that similarly:
struct t
{
char a:4;
short b:16;
char c:4;
} __attribute__ ((packed))
would come out to be 4 bytes long. However,
[ DJ Delorie Cc'd in as libiberty maintainer ]
Hi DJ,
We're having a bit of build trouble for GCC HEAD on Cygwin: to recap, ...
Dave Korn wrote:
Andy Scott wrote:
../../../gcc/libiberty/strsignal.c -o strsignal.o
../../../gcc/libiberty/strsignal.c:408: error: conflicting types for
IIRC, that whole clause was because cygwin's dll itself linked with
libiberty, so the auto-detect stuff needed an override to make sure
the right files were there when you build cygwin1.dll. Otherwise, it
would detect that cygwin had strsignal, not build it, then fail later
when cygwin1.dll
--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-15 08:07 ---
Subject: Bug 38245
Author: jakub
Date: Thu Jan 15 08:07:38 2009
New Revision: 143387
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143387
Log:
PR rtl-optimization/38245
* calls.c
--- Comment #24 from jakub at gcc dot gnu dot org 2009-01-15 08:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Testcase:
void noop(char* foo) {}
For 64-bit it does the right thing:
$ gcc -O2 foo.c -S
Output is:
noop:
.LFB2:
rep
ret
However for 32-bit it has useless extra instructions:
$ gcc -m32 -O2 foo.c -S
noop:
pushl %ebp
movl%esp, %ebp
popl%ebp
--- Comment #2 from pault at gcc dot gnu dot org 2009-01-15 09:19 ---
(In reply to comment #1)
This would mean an ABI change, but it is worth thinking about.
The required fix is trivial, although I have not regtested yet; eliminate
1127-1131 in trans-common.c.
Cheers
Paul
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 09:45 ---
This is the frame-pointer setup code. You can get the same code as x86_64 with
-momit-leaf-frame-pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from edwintorok at gmail dot com 2009-01-15 09:50 ---
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push ebp, write something to it, and
--- Comment #3 from edwintorok at gmail dot com 2009-01-15 09:51 ---
(In reply to comment #2)
(In reply to comment #1)
This is the frame-pointer setup code. You can get the same code as x86_64
with
-momit-leaf-frame-pointer.
Ok. But can't the optimizers see that you push
--- Comment #25 from ramana at icerasemi dot com 2009-01-15 10:34 ---
Redo CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #14 from ramana at icerasemi dot com 2009-01-15 10:35 ---
Redo CCs
--
ramana at icerasemi dot com changed:
What|Removed |Added
CC|
--- Comment #7 from ramana at icerasemi dot com 2009-01-15 10:37 ---
Change CC addresses
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #10 from ramana at icerasemi dot com 2009-01-15 10:37 ---
Change CC addresses
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #6 from ramana at icerasemi dot com 2009-01-15 10:38 ---
Change CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #15 from ramana at icerasemi dot com 2009-01-15 10:41 ---
Add self to CC
--
ramana at icerasemi dot com changed:
What|Removed |Added
CC|
--- Comment #7 from ramana at icerasemi dot com 2009-01-15 10:38 ---
Change CC addresses.
--
ramana at icerasemi dot com changed:
What|Removed |Added
--- Comment #20 from m dot reszat at kostal dot com 2009-01-15 11:15
---
There's a couple of things worth mentioning, based on the documentation. Quote:
`-finline-small-functions'
Integrate functions into their callers when their body is smaller
than expected function call
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-15 11:15 ---
Re. #3
Yes, the pro/epilogues are special.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
--- Comment #12 from amylaar at gcc dot gnu dot org 2009-01-15 11:36
---
(In reply to comment #11)
P.S.:
Another feature that we could look at is the number of times an input
ssa name is used. If it is used more than once, we cannot rely on the
original ssa name to go away, and hence
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-01-15 11:44
---
I'm working on adding rvalue support to bind etc. but time is not on my side
recently. I hope to make some more progress this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
--- Comment #4 from rbenedik at fsmat dot htu dot tuwien dot ac dot at
2009-01-15 12:12 ---
I traced the error back to a iteration scheme which is not stable when optmized
with -O2. Sorry this was my fault, so theres no Bug in -O2:
DTYPE FTYPE(SQUARE_ROOT)(DTYPE A)
{
DTYPE X_N1;
--- Comment #2 from dodji at gcc dot gnu dot org 2009-01-15 13:01 ---
Subject: Bug 38636
Author: dodji
Date: Thu Jan 15 13:01:36 2009
New Revision: 143392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143392
Log:
gcc/cp/ChangeLog:
2009-01-13 Dodji Seketeli do...@redhat.com
--- Comment #22 from r dot emrich at de dot tecosim dot com 2009-01-15
13:07 ---
(In reply to comment #21)
libtool uses the following regex:
(s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]
This matches for the native file command output:
libm.2:
---code---
#include iostream
#include iomanip
using namespace std;
int main() {
float f(1.0);
// cout Value: ; // works with any cout before eval!!
unsigned int i = *reinterpret_castunsigned int*(f);
cout hex i endl;
cout sizeof(float) endl;
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-15 13:46 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-15 13:57 ---
Fixed on the trunk:
-O2:
movzbl %dil, %edi
movzwl -2(%rsi,%rdi,2), %eax
ret
-Os:
movzbl %dil, %edi
movw-2(%rsi,%rdi,2), %ax
ret
--
jakub at gcc dot gnu dot
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:35 ---
Thus invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
IMHO it's unwanted to remove the frame setup for empty functions without
-momit-leaf-frame-pointer. Debuggers may need it to do backtraces from
within that function.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-15 14:37 ---
It is not. You are violating C++ aliasing rules. Use memcpy or a union.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jakub at gcc dot gnu dot org 2009-01-15 15:08 ---
Please s/incomoing/incoming/g in the patch. Otherwise the patch makes a lot of
sense to me. As INCOMING_STACK_BOUNDARY is used not only in
expand_stack_alignment, but also in 386's targetm.function_ok_for_sibcall
--- Comment #8 from ronan dot lehy at probayes dot com 2009-01-15 15:13
---
If I add simple explicit instantiations in place or in addition to the
BOOST_CLASS_EXPORT() calls, all symbols are correctly exposed in all cases :
namespace boost {
namespace serialization {
--- Comment #24 from hjl dot tools at gmail dot com 2009-01-15 15:18
---
Created an attachment (id=17107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17107action=view)
Here is the updated patch.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #25 from dnovillo at gcc dot gnu dot org 2009-01-15 15:23
---
(In reply to comment #24)
Created an attachment (id=17107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17107action=view) [edit]
Here is the updated patch.
OK.
Diego.
--
--- Comment #26 from hjl at gcc dot gnu dot org 2009-01-15 15:44 ---
Subject: Bug 37843
Author: hjl
Date: Thu Jan 15 15:44:41 2009
New Revision: 143400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143400
Log:
gcc/
2009-01-15 H.J. Lu hongjiu...@intel.com
Joey Ye
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38554
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38789
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-15 16:00 ---
Maybe not really P1, but we certainly should investigate why tree-ssa broke
this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:03 ---
Honza, can you please have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-15 16:05 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Works for me with checking disabled. Not worth fixing on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-15 16:08 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:09 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-15 16:10 ---
Fixed for GCC 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-15 16:12 ---
Fixed for GCC 4.4. Works for me on the branch with checking disabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ronan dot lehy at probayes dot com 2009-01-15 16:12
---
Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
it is (very) roughly equivalent to this:
void dummy(boost::archive::xml_iarchive ar, A a, B b) {
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.1 4.3.0 |4.0.0 4.3.2
Known to work|3.3 4.4.0 |3.3.6
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38751
--- Comment #27 from jakub at gcc dot gnu dot org 2009-01-15 16:28 ---
Fixed, thanks.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at gcc dot gnu dot org 2009-01-15 18:08 ---
Subject: Bug 38357
Author: sje
Date: Thu Jan 15 18:07:46 2009
New Revision: 143402
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143402
Log:
PR c++/38357
* pt.c (tsubst): Check for NULL args.
--- 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=gccview=revrev=143403
Log:
PR c++/38357
* g++.dg/template/crash87.C: New test.
--- 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=gccview=revrev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c
--- 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=gccview=revrev=143404
Log:
PR c++/36334
PR c++/37646
* tree.c
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 #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
--- 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 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
--- 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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
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
--- 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
--- 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 #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
--- 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 #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
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
--- 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 @@
--- 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=gccview=revrev=143406
Log:
2009-01-15 Benjamin Kosnik b...@redhat.com
PR
--- 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
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 aczapran at hotmail dot com 2009-01-15 20:09 ---
Created an attachment (id=17108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17108action=view)
preprocessed file attaced = a.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38860
--- 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 is missing otherwise
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 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.
--
--- 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_
--- 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
--- 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
--- 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=17109action=view)
Order BACKENDLIBS by dependencies.
I'd consider this fix obvious. Verified that it resolves the
[ 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
--- 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
--- 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
1 - 100 of 168 matches
Mail list logo
