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 ICE?
--- 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=21276&action=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
AssignedTo|unassigned
--- 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.
--
http://gcc.gnu.org/bugzill
--- 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=gcc&view=rev&rev=162364
Log:
PR debug/45003
* var-tracking.c (reverse_op): Als
--- 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
poin
--- 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=gcc&view=rev&rev=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
AssignedTo|u
--- 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=gcc&view=rev&rev=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
St
--
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=21277&action=view)
debug log
I think the problem is that fixed_scalar_and_varying_struct_p is called with a
VALUE address, i.e. no
--- 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 (MEM_VOLATI
--- 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 bu
--- 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
AssignedTo|u
--- 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 t
--- 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 bo
--- 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 fi
--- 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, since
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
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=gcc&view=rev&rev=162371
Log:
2010-07-21 Richard Guenther
PR middle-end/45013
static inline int __gthread_active_p (void) { }
template class Tensor;
template struct G;
template class T {
typedef void A;
typedef Tensor<1,dim> F[G::v];
};
> ./cc1plus -quiet fe.3.ii -flto
fe.3.ii:7:2: internal compiler error: tree check: did not expect class 'type',
have 'type' (rec
--- 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
AssignedTo|
--- 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=gcc&view=rev&rev=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=21278&action=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 lo
--- 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
_ZN1CC[12]Ev:
--- 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=gcc&view=rev&rev=162374
Log:
2010-07-21 Martin Jambor
PR tree-optimization/4
--- 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=gcc&view=rev&rev=162375
Log:
2010-07-21 Martin Jambor
PR tree-optimization/4
to/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-1_0.C
--- 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; };
template struct T { };
T<&S::f> v;
For v's type, I just
--- 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=gcc&view=rev&rev=162381
Log:
Fix PR 44955: Strip off the real and complex parts.
2010-07-21 Ch
--- 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:
<1><4f>: 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), in
--- 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 r16184
--- 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 one
--- 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=rev&revision=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 compi
--- 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->
--- 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?
Fee
--- 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
--- 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-e
--- 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" n
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 "v\
--- 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 pa
--- 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
Status|ASSIGNE
--- 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=21279&action=view)
Proposed fix
I'm testing this patch as a fix. Will submit it tomorrow if everything goes
fine.
--
http://
--- 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 `typ
--- 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 the
--- 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 misundersto
--- 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; i<1024; i++)
a[i] = a[i] + beta * b[i];
}
with gcc -O3 -fprefetch-loop-arrays -march=amdfam10 -S, a piece o
--- 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=21280&action=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 refers
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)
{
in
--- 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...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
--- 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
#include
int main()
{
try
{
throw std::runtime_error("This is a test");
}
catch (std::exception& ex)
{
std::cerr << ex.what() << std::endl;
}
return 0;
}
--
Summary: Mudflap on
--- 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 { };
template struct T { };
};
S sval;
S::sint sintval;
S::Q qval;
S::T tval;
In the generated DWARF, "sint" and "Q" are child DIEs of the DIE for S, e.g.:
<1><25>: Abbrev Number:
--- 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 It
--- 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 eith
--- 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=gcc&view=rev&rev=162383
Log:
IA64 uses // instead of # for comments in its assembly fil
--- Comment #10 from jyasskin at gcc dot gnu dot org 2010-07-21 18:48
---
Fixed by r162383.
--
jyasskin at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-21 19:12 ---
Subject: Bug 45015
Author: jakub
Date: Wed Jul 21 19:11:55 2010
New Revision: 162385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162385
Log:
PR debug/45015
* var-tracking.c (adjust_mems): Ig
--- Comment #11 from manu at gcc dot gnu dot org 2010-07-21 19:40 ---
(In reply to comment #8)
> Despite your remarkably rude response, I've mailed a fix:
> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01665.html
Don't take it personally. Some of us are not native English-speakers, so w
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-21 20:54 ---
Fixed with MEM_REF.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-21 21:00 ---
Optimizes to an empty function for me with r162374.
Probably thanks to Martin's SRA rewrite.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
st8 [r14] = r38
nop 0
adds r14 = 56, r12
;;
.mib
st8 [r14] = r39
.restore sp
adds r12 = 48, r12
br.ret.sptk.many b0
.endp copystruct5#
.ident "GCC: (GNU) 4.6.0 20100721 (experimental) [trunk revision
162374
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-21 21:09 ---
The SRA rewrite for GCC 4.6 probably fixes the SRA part of this bug report (at
last!).
Can someone with a powerpc box have a look?
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #23 from changpeng dot fang at amd dot com 2010-07-21 21:30
---
Fixed
--
changpeng dot fang at amd dot com changed:
What|Removed |Added
Status|NE
--- Comment #31 from armand dot potter at free dot fr 2010-07-21 21:35
---
I made some more investigations (a bit late as I am using now
--disable-libpchstdcxx like everyone else). IMHO three main options are
possible :
1/ Use -nostdinc++ just as native compilers do. Like said in comme
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-21 21:37 ---
(In reply to comment #5)
> > Maybe that's indeed a question for either the j3 mailing list or for c.l.f.
>
> I have now asked at
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9849942aca1d54f
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-21 21:43 ---
Even with 4.5.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone
--- Comment #39 from pthaugen at gcc dot gnu dot org 2010-07-21 21:51
---
(In reply to comment #38)
>
> .L2:
> addi 11,8,9216
> ldx 0,10,9
> stdx 0,11,9
> addi 9,9,8
> bdnz .L2
>
> and in r161844:
>
> .L2:
> ldu 0,8(11)
> stdu 0
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-21 21:53 ---
9 years
0 progress
Tom?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 132 matches
Mail list logo
