HI:
found mult-acc insns like madd.s/d are only used when -mfp64 is specified,
as to codes, there macros defined as:
#define ISA_HAS_FP4 ((ISA_MIPS4 \
|| (ISA_MIPS32R2 TARGET_FLOAT64) \
--only float 64
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for software FP.
I use the
Hi,
You mean I should define insn like this:
(define_insn *iorqi3_imm
[(set (mem:QI (match_operand:HI 0 register_operand b))
(ior:QI (mem:QI (match_operand:HI 1 register_operand b)
(mem:QI (plus: HI (match_operand:HI 2 register_operand
f)
Hello,
Back in 2001, GCC could disambiguate almost no MEMs on ia64 because
ia64 has no (reg+offs) addressing modes. Bernd added a trick to alias
and to sched-ebb to use cselib, to substitute a reg address with a
reg+offs address recorded by cselib (see
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
It looks like ~9% extra !true_dependence cases are found with cselib,
with is not insignificant:
situationcalls depends ratio
with_cselib 186764 70463 0.377284
asis 186764 76375 0.408939 (i.e. no cselib)
On the other
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
3. GCC now has better alias analysis than it used to, especially with
the alias-exporting stuff that exports the GIMPLE points-to analysis
results, but also just all the other little things that were
contributed over the last 10 years (little
On Wed, Jul 21, 2010 at 4:44 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
3. GCC now has better alias analysis than it used to, especially with
the alias-exporting stuff that exports the GIMPLE points-to analysis
results, but also just all the
Cedric Roux-4 wrote:
Tim Prince wrote:
On 7/19/2010 4:13 PM, IceColdBeer wrote:
Hi,
I'm building a project using GNU gcc, but the command line used to build
each source file sometimes exceeds 8191 characters, which is the maximum
supported command line length under Win XP.Even
On Wed, Jul 21, 2010 at 04:57:10PM +0200, Steven Bosscher wrote:
On Wed, Jul 21, 2010 at 4:44 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
3. GCC now has better alias analysis than it used to, especially with
the alias-exporting stuff
On Wed, Jul 21, 2010 at 5:14 PM, Jakub Jelinek ja...@redhat.com wrote:
If that can't be improved, I think that rather than remove cselib from
the scheduler, the question should be: if it's useful, why don't we use
it for other schedulers rather than only sched-ebb?
Well, for one thing: It
On 7/21/10 6:44 PM, Bernd Schmidt wrote:
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
3. GCC now has better alias analysis than it used to, especially with
the alias-exporting stuff that exports the GIMPLE points-to analysis
results, but also just all the other little things that were
On Wed, Jul 21, 2010 at 10:09 PM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
Cselib can /always/ be used during second scheduling pass
Except with the selective scheduler when it works on regions that are
not extended basic blocks, I suppose?
and on
single-block regions during the first
I'm trying the attached patch over sh-softfp-20100718-2131 patch.
All regressions go away with it on cross sh4-unknown-linux-gnu,
though the native bootstrap will take a few days more.
There are a few warnings in bootstrap:
../trunk/gcc/config/sh/sh.c: In function 'sh_soft_fp_cmp':
--- Comment #3 from nilssch at informatik dot uni-bremen dot de 2010-07-21
06:29 ---
Same here on debian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008
The fix for PR43051 causes ICE when building GLIBC for ColdFire Linux.
The problem was made latent on trunk by the fix for PR44492 (rev. 161328). It
doesn't look like this patch fixes the underlying problem, but I may be wrong.
Jacub,
Do you think the fix for PR44492 legitimately fixes the
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 07:20
---
Created an attachment (id=21276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21276action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
--- Comment #33 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-07-21
07:56 ---
Subject: Re: [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2010-07-21 04:37
---
--- Comment #12 from rguenther at suse dot de 2010-07-21 08:09 ---
Subject: Re: INTENT(IN) etc. optimization of calls:
function annotations for noclobber/noescape arguments
On Tue, 20 Jul 2010, burnus at gcc dot gnu dot org wrote:
--- Comment #11 from burnus at gcc dot gnu dot
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-21 08:11 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-21 08:22 ---
OK, I think I finally understand what Alexander tried to explain, and I've
annotated the code. Alexander, does this look right to you?
f1: // vector int f1(vector int t)
.mmi
--- Comment #13 from jamborm at gcc dot gnu dot org 2010-07-21 08:27
---
(In reply to comment #12)
So I wonder what code removes the arguments then.
IPA-CP can do that for quite some time please try with -fno-ipa-cp.
(I don't have a trunk built with enabled fortran at hand and I
--- Comment #17 from amonakov at gcc dot gnu dot org 2010-07-21 08:32
---
(In reply to comment #16)
OK, I think I finally understand what Alexander tried to explain, and I've
annotated the code. Alexander, does this look right to you?
Yes, thanks.
--
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-21 08:51 ---
Subject: Bug 45003
Author: jakub
Date: Wed Jul 21 08:50:57 2010
New Revision: 162364
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162364
Log:
PR debug/45003
* var-tracking.c (reverse_op): Also
--- Comment #5 from jakub at gcc dot gnu dot org 2010-07-21 08:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-21 09:03 ---
Fortran 2008 has the following, which I missed to quote:
If bounds-remapping-list is specified, the pointer target shall be simply
contiguous (6.5.4) or of rank one. It shall not be a disassociated or undefined
--- Comment #34 from ro at gcc dot gnu dot org 2010-07-21 09:06 ---
Subject: Bug 38946
Author: ro
Date: Wed Jul 21 09:05:47 2010
New Revision: 162366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162366
Log:
Backport from mainline:
2010-06-25 Jerry DeLisle
--- Comment #5 from domob at gcc dot gnu dot org 2010-07-21 09:06 ---
I'll work on this.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from ro at gcc dot gnu dot org 2010-07-21 09:06 ---
Subject: Bug 38946
Author: ro
Date: Wed Jul 21 09:06:42 2010
New Revision: 162367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162367
Log:
Backport from mainline:
2010-06-25 Jerry DeLisle
--- Comment #36 from ro at gcc dot gnu dot org 2010-07-21 09:09 ---
Fixed on all active branches.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45014
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45009
--- Comment #18 from steven at gcc dot gnu dot org 2010-07-21 09:27 ---
Created an attachment (id=21277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21277action=view)
debug log
I think the problem is that fixed_scalar_and_varying_struct_p is called with a
VALUE address, i.e. not
--- Comment #19 from steven at gcc dot gnu dot org 2010-07-21 09:33 ---
x_addr is a VALUE that has no locs:
Breakpoint 4, true_dependence (mem=0x205ddf68, mem_mode=VOIDmode,
x=0x205ddfb0, varies=0x20496720) at
../../trunk/gcc/alias.c:2330
2330 if
--- Comment #20 from steven at gcc dot gnu dot org 2010-07-21 09:49 ---
Since this bug only triggers if cselib is used, the bug affects schedule_ebbs
only. The other schedulers are !use_cselib schedulers.
(Even sel-sched apparently does not use cselib, that's surprising!)
OTOH, this
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-21 09:54 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-21 09:58 ---
Look at the ia64 port (and a few others too, e.g. blackfin), they call
compute_bb_for_insn first thing in machine reorg and that works. It is
obviously not ideal, but the only pass between free_cfg and machine_reorg
--- Comment #21 from amonakov at gcc dot gnu dot org 2010-07-21 10:07
---
(In reply to comment #20)
(Even sel-sched apparently does not use cselib, that's surprising!)
Offtopic: yes, using cselib in sel-sched is not quite straightforward, since we
need it to work on arbitrary regions
This PR is about two related topics:
a) Wrong code: Fortran 90+: The lower bound shall be the same as the one of the
object on the RHS
b) F2003+ pointer assignment with bounds-spec
Related to PR 29785 (bounds remapping).
* * *
a) WRONG CODE
The test case should print twice a lower bound of 2,
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-21 10:14 ---
See also PR 45016, which is not about bounds remapping but about setting the
correct bounds in an array assignment. (Wrong-code F95 bug + missing F2003
feature).
Maybe all three (remapping, fix bounds, F2003 lower
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-21 10:18 ---
Mark as regression; for p = a GCC 4.3.2 prints the correct bounds (2 2). I
currently cannot try 4.4 or 4.5.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-21 10:26 ---
Scratch the regression thing. (a) Works also with 4.6. I accidentally was
running 4.1.2 (system compiler, gfortran) instead of 4.6.0 (gfortran46).
[On my usual system gfortran = 4.6.]
However, (b) is still true.
--- Comment #4 from allan at archlinux dot org 2010-07-21 10:47 ---
Limiting the timeframe where this became fixed on mailine:
4.5.0 20100401 fails
4.6.0 20100416 works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008
--- Comment #5 from paolo dot carlini at oracle dot com 2010-07-21 10:49
---
Jason, can you have a look to this weird issue? To repeat, I can reproduce it
only in 4_5-branch, not in mainline nor in 4_4-branch (thus looks like a
regression) and of course doesn't happen if a single cpp
--- Comment #12 from hubicka at ucw dot cz 2010-07-21 11:05 ---
Subject: Re: weak aliases LTO with gold causes ICE in
lto_symtab_merge_decls_1
If you link .c and .s produced objects into single .o file via incremental
linking, you probably get all the assembly
files lost,
The following testcase has a different result with 4.6 and -O1/2/3
gcc4.5: all optimizations:
r1: 15 r2: 2
gcc4.6: -O0
r1: 15 r2: 2
gcc4.6: -O1,-O2..
r1: 47 r2: 2
#include stdio.h
int tester(char *bytes)
{
union {
struct {
unsigned int r1:4;
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-21 11:45 ---
Subject: Bug 45013
Author: rguenth
Date: Wed Jul 21 11:45:27 2010
New Revision: 162371
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162371
Log:
2010-07-21 Richard Guenther rguent...@suse.de
PR
static inline int __gthread_active_p (void) { }
template int rank, int dim class Tensor;
template int dimension struct G;
template int dim class T {
typedef void A;
typedef Tensor1,dim F[Gdim::v];
};
./cc1plus -quiet fe.3.ii -flto
fe.3.ii:7:2: internal compiler error: tree check: did not
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-21 12:06 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-21 12:08 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #5 from bernds at gcc dot gnu dot org 2010-07-21 12:37 ---
Subject: Bug 44738
Author: bernds
Date: Wed Jul 21 12:36:44 2010
New Revision: 162372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162372
Log:
PR middle-end/44738
* tree-ssa.c (warn_uninit):
--- Comment #6 from bernds at gcc dot gnu dot org 2010-07-21 12:39 ---
Fixed.
--
bernds at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-21 12:40 ---
Created an attachment (id=21278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21278action=view)
gcc46-pr45015.patch
Untested fix (together with testcase that fails even with current trunk without
the patch).
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-07-21 12:51 ---
With MEM_REFs we now have fewer explicit typecasts and this has made
replace_uses_with_default_def_ssa_name create invalid statements.
FYI, this is not the ordinary replacing code path but rather the one
removing
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-21 13:30 ---
Those tests failed on Linux/ia64:
FAIL: g++.dg/debug/dwarf2/lineno-simple1.C scan-assembler
_ZN1C3fooEv:[^\\t]*(\\t.file[^\\t]*)?\\t# \\S*:6\\n
FAIL: g++.dg/debug/dwarf2/lineno-simple1.C scan-assembler
--- Comment #25 from jamborm at gcc dot gnu dot org 2010-07-21 13:57
---
Subject: Bug 44900
Author: jamborm
Date: Wed Jul 21 13:57:12 2010
New Revision: 162374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162374
Log:
2010-07-21 Martin Jambor mjam...@suse.cz
PR
--- Comment #26 from jamborm at gcc dot gnu dot org 2010-07-21 14:17
---
Subject: Bug 44900
Author: jamborm
Date: Wed Jul 21 14:17:11 2010
New Revision: 162375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162375
Log:
2010-07-21 Martin Jambor mjam...@suse.cz
PR
lto/45018
* tree.c (find_decls_types_r): Do not follow TREE_CHAIN
of TYPE_DECLs. Do not follow TYPE_NEXT_VARIANT,
TYPE_NEXT_PTR_TO, nor TYPE_NEXT_REF_TO or TYPE_CANONICAL.
* g++.dg/lto/20100721-1_0.C: New testcase.
Added:
trunk/gcc/testsuite/g++.dg/lto/20100721
--- Comment #3 from tromey at gcc dot gnu dot org 2010-07-21 15:19 ---
The ordinary cases work fine with svn trunk gcc.
However, member pointers still don't have all the info emitted.
Consider this test case:
struct S { int f; };
templateint S::*MP struct T { };
TS::f v;
For v's type,
--- Comment #13 from andi-gcc at firstfloor dot org 2010-07-21 15:21
---
I know I lost some assembler files, but I think I didn't lose all of them.
Some assembler code is still there. Any suggestion how to fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
The following program:
MODULE m
IMPLICIT NONE
INTEGER, TARGET :: arr(3)
CONTAINS
SUBROUTINE foobar (arg)
INTEGER, TARGET :: arg(:)
arr(2:3) = arg(1:2)
END SUBROUTINE foobar
END MODULE m
PROGRAM main
USE :: m
IMPLICIT NONE
arr = (/ 1, 2, 3 /)
CALL foobar (arr)
PRINT
--- Comment #3 from spop at gcc dot gnu dot org 2010-07-21 15:44 ---
Subject: Bug 44955
Author: spop
Date: Wed Jul 21 15:44:24 2010
New Revision: 162381
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162381
Log:
Fix PR 44955: Strip off the real and complex parts.
2010-07-21
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-21 15:50 ---
Am I allowed to confirm my own bugs? doing so anyway
There's no difference when using -gdwarf-2 -gstrict-dwarf
readelf -wi for the output of g++ 4.5 shows S::ptr as:
14f: Abbrev Number: 5 (DW_TAG_pointer_type)
--- Comment #7 from hp at gcc dot gnu dot org 2010-07-21 15:54 ---
Correcting the summary to point at the right cause. Maybe the following
somewhat obvious change is correct, though I'd prefer to leave it to Bernd.
Index: postreload.c
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-21 15:57 ---
Confirm. Fails with ifort, gfortran 4.1 and 4.6, and with pgf90. Works with
Crayftn and Pathscale.
I think the scalar constraint does not matter (it's not a restricted pointer as
both actual and dummy are TARGET),
--- Comment #38 from sandra at codesourcery dot com 2010-07-21 16:08
---
On reading the code again, I think the -7 is coming from the can_autoinc case
in determine_use_iv_cost_address. I also think it is correct to prefer
autoinc. E.g., here's the generated code for the loop in
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-21 16:13 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-21 16:20 ---
Confirmed. This is caused by mem-ref VN. Thus, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2010-07-21 16:24 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-21 16:32 ---
For completeness: In F2003, see Section 12.4.1.7 (3)(b) and in F95 see 12.4.1.6
(1)(c).
dependency.c's gfc_check_dependency is the place where a check needs to be
added. As pointerness is already checked, I think
--- Comment #13 from armin76 at gentoo dot org 2010-07-21 16:34 ---
(In reply to comment #7)
we've hit this with gcc-4.3.3 with arm-softfloat-linux-gnueabi targets, and
the
commit in question was for PR38000:
http://gcc.gnu.org/viewcvs?view=revrevision=143194
[snip]
Is this
--- Comment #5 from walton at seas dot harvard dot edu 2010-07-21 16:35
---
Subject: Re: Name of member class of template class cannot
be used as argument type.
OK, adding `typename::' fixed the problem with the compiler
balking at the template function definition, but now
the
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-21 16:44 ---
(In reply to comment #2)
if (sym1.attr.target sym2-attr.target
Actually, I wonder whether this is really testable:
the actual argument is a target
thus, one probably needs to use:
sym1 = expr1-symtree-n.sym;
--- Comment #6 from jyasskin at gcc dot gnu dot org 2010-07-21 16:44
---
Is the problem a bad mangling or bad line numbers? In a built tree, could you
run:
$objdir/gcc/cc1plus -g -dA
$srcdir/gcc/testsuite/g++.dg/debug/dwarf2/pr44641.C -o pr44641.s
and send me or attach pr44641.s?
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-21 16:50 ---
(In reply to comment #6)
Is the problem a bad mangling or bad line numbers? In a built tree, could you
run:
$objdir/gcc/cc1plus -g -dA
$srcdir/gcc/testsuite/g++.dg/debug/dwarf2/pr44641.C -o pr44641.s
and send
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-21 16:57 ---
(In reply to comment #3)
Actually, I wonder whether this is really testable:
the actual argument is a target
thus, one probably needs to use:
The other question is how to deal with the restrict middle-end
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-21 17:11 ---
(In reply to comment #5)
OK, adding `typename::' fixed the problem with the compiler
That should be just typename, it's not a namespace. When the standard says
qualified with typename it means typename T::A not
The C FE (unlike C++) generates extra DW_TAG_variable in the debug info for
e.g.
extern int v;
__typeof (v) v;
or
extern int v;
__typeof (v) w;
int v = 456;
or
extern int v;
int foo (void) { return v; }
int v;
The first one gives with -g -dA:
.uleb128 0x2 # (DIE (0x2d) DW_TAG_variable)
.ascii
--- Comment #5 from jamborm at gcc dot gnu dot org 2010-07-21 17:19 ---
(In reply to comment #4)
Based on the last post in the patch thread should the patch be committed so
the
testsuite failures go away and this can be closed?
I do not think I got an approval to commit the
--- Comment #27 from jamborm at gcc dot gnu dot org 2010-07-21 17:21
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-07-21 17:29 ---
Created an attachment (id=21279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21279action=view)
Proposed fix
I'm testing this patch as a fix. Will submit it tomorrow if everything goes
fine.
--
--- Comment #7 from walton at seas dot harvard dot edu 2010-07-21 17:30
---
Subject: Re: Name of member class of template class cannot
be used as argument type.
Replacing '::' with ' ' does not change the error message. I don't
think you are right about the compiler mistaking
--- Comment #8 from walton at seas dot harvard dot edu 2010-07-21 17:35
---
Subject: Re: Name of member class of template class cannot
be used as argument type.
Oh, I see. You are just telling me that the '::' will be interpreted
as a global namespace indicator. In the case of
--- Comment #9 from redi at gcc dot gnu dot org 2010-07-21 17:37 ---
(In reply to comment #7)
Replacing '::' with ' ' does not change the error message. I don't
Did you miss the rest of my reply? I wasn't suggesting that would fix the
error, I was pointing out you've
--- Comment #10 from redi at gcc dot gnu dot org 2010-07-21 17:38 ---
(In reply to comment #8)
Subject: Re: Name of member class of template class cannot
be used as argument type.
Oh, I see. You are just telling me that the '::' will be interpreted
as a global namespace
For the following test case, prefetches will be inserted for both the load and
store of a[i] if the loop is vectorized:
float a[1024], b[1024];
void foo(int beta)
{
int i;
for(i=0; i1024; i++)
a[i] = a[i] + beta * b[i];
}
with gcc -O3 -fprefetch-loop-arrays -march=amdfam10 -S, a piece
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 17:58
---
Created an attachment (id=21280)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21280action=view)
Testcase for patch
Thanks for looking into this problem!
The patch fixes the original testcase but causes a
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-21 18:00 ---
Another testcase:
extern int v;
extern __typeof (v) v;
extern __typeof (v) v;
When the old extern decl isn't TREE_USED, it doesn't make it into debug info:
case VAR_DECL:
/* Ignore this VAR_DECL if it
For the following test case, if we compile with -O3 -fprefetch-loop-arrays
-march=amdfam10, the loop is versioned (for runtime alias checking) to be
vectorized. However, we see prefetches in the non-vectorize version, but
not in the vectorized version.
void foo(int beta, float *a, float *b)
{
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-21 18:05 ---
Can't reproduce that. Were you testing the patch attached here, or the one
posted to gcc-patches? The one attached here won't work when not
ENABLE_CHECKING...
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-21 18:06 ---
The misaligned indirect-refs will vanish soon.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 18:20
---
Subject: Re: ICE in cselib.c caused by fix for PR43051
On 7/21/10 10:05 PM, jakub at gcc dot gnu dot org wrote:
--- Comment #4 from jakub at gcc dot gnu dot org 2010-07-21 18:05 ---
Can't reproduce
The following code generates a mudflap violation.
#include iostream
#include stdexcept
int main()
{
try
{
throw std::runtime_error(This is a test);
}
catch (std::exception ex)
{
std::cerr ex.what() std::endl;
}
return 0;
}
--
Summary:
--- Comment #1 from changpeng dot fang at amd dot com 2010-07-21 18:26
---
The direct reason is that prefetching could not differentiate the base
addresses
of the vectorized load and store (of a[i]):
*vect_pa.6_24
*vect_pa.19_37
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45021
I'm using gcc svn trunk as of yesterday.
Consider this test case:
struct S {
typedef int sint;
struct Q { };
templatetypename Z struct T { };
};
S sval;
S::sint sintval;
S::Q qval;
S::Tint tval;
In the generated DWARF, sint and Q are child DIEs of the DIE for S, e.g.:
125: Abbrev
--- Comment #8 from jyasskin at gcc dot gnu dot org 2010-07-21 18:42
---
Despite your remarkably rude response, I've mailed a fix:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01665.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
This is really a continuation of bug 42869, but that title mentions Itanium,
and this is not Itanium-specific.
Gomp_mutex_lock and as a result OpenMP critical sections and locks do not
implement sane memory ordering semantics. This is largely due to __sync
implementation problems. I looked at
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-21 18:43 ---
(In reply to comment #4)
For instance:
arr(1) = 5
arg(1) = 6
if (arg(1) /= 6) call abort()
Make that arr(1) in the last line - otherwise it is pointless.
Maybe that's indeed a question for either
--- Comment #9 from jyasskin at gcc dot gnu dot org 2010-07-21 18:47
---
Subject: Bug 44641
Author: jyasskin
Date: Wed Jul 21 18:46:40 2010
New Revision: 162383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162383
Log:
IA64 uses // instead of # for comments in its assembly
1 - 100 of 140 matches
Mail list logo
