--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 06:48 ---
Should be fixed now for 4.4+.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-22 06:46 ---
Should be fixed now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from jakub at gcc dot gnu dot org 2010-07-22 06:46 ---
Subject: Bug 44942
Author: jakub
Date: Thu Jul 22 06:46:28 2010
New Revision: 162399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162399
Log:
Backport from mainline
2010-07-16 Jakub Jelinek
--- Comment #7 from burnus at gcc dot gnu dot org 2010-07-22 06:44 ---
> (In reply to comment #5)
> > I have now asked at
Seemingly, I break the dependency chain in comment 3; thus, only with an added
"TARGET" in the module variable declaration and with an assumed-shaped dummy in
"bar"
--- Comment #6 from jakub at gcc dot gnu dot org 2010-07-22 06:42 ---
Subject: Bug 44942
Author: jakub
Date: Thu Jul 22 06:42:02 2010
New Revision: 162398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162398
Log:
Backport from mainline
2010-07-16 Jakub Jelinek
--- Comment #7 from jakub at gcc dot gnu dot org 2010-07-22 06:38 ---
Subject: Bug 45015
Author: jakub
Date: Thu Jul 22 06:38:25 2010
New Revision: 162397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162397
Log:
PR debug/45015
* var-tracking.c (adjust_mems): Ig
--- Comment #6 from allan at archlinux dot org 2010-07-22 03:53 ---
Applying this commit from PR43016 to gcc-4.5 fixes the issue:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158095
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45008
--- Comment #9 from hp at gcc dot gnu dot org 2010-07-22 02:43 ---
Confirmed fixed, r162392 tested, no regressions compared to r162328.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-07-22 00:02 ---
So closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-07-22 00:01
---
The C++ standard actually requires this as noted in comment #5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-22 00:00 ---
Since this code is undefined ISO C/C++ code, changing the behavior is valid so
closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-21 23:53 ---
I think libmudflapth does have a dependency on libpthread which is causing this
issue. I think libmudflapth have a weak check in it too.
w pthread_join
--
pinskia at gcc dot gnu dot org changed
--- Comment #6 from dje at gcc dot gnu dot org 2010-07-21 23:52 ---
I think the thread about the patch became confused.
First, Janis essentially approved the testsuite patch.
Second, Martin commented that the failure probably was due to MOVE_RATIO not
defined. The statement caused som
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-21 23:45 ---
It is the gimplification of SWITCH_STMT which is a C++ front-end tree.
Works with the C front-end too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from rob1weld at aol dot com 2010-07-21 23:17 ---
(In reply to comment #17)
> Subject: Re: Configure scripts have no 64-Bit Solaris defined (only
> i386-solaris*).
>
> > --- Comment #16 from rob1weld at aol dot com 2010-07-20 19:02 ---
> > (In reply to comment
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-21 23:14 ---
It is caused by revision 162384:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00738.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-21 22:56 ---
>const int i = 0;-fzero-initialized-in-bss -> .rodata = FAIL
This is correct because it should really be in readonly data section as it is
constant.
--
pinskia at gcc dot gnu dot org changed:
Wha
--- Comment #6 from kargl at gcc dot gnu dot org 2010-07-21 22:50 ---
I'm closing this PR as FIXED such that I reverted the patch
that caused the problem and re-opened PR fortran/44929.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-07-21 22:51 ---
For some reason rs6000 has an abssi pattern but it is not produced by ce1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
On Linux/x86-64, revision 162385 gave
FAIL: c-c++-common/dfp/pr36800.c execution test
FAIL: c-c++-common/dfp/pr36800.c execution test
Revision 162382 is OK.
--
Summary: [4.6 Regression] FAIL: c-c++-common/dfp/pr36800.c
Product: gcc
Version: 4.6.0
St
--- Comment #15 from kargl at gcc dot gnu dot org 2010-07-21 22:49 ---
Re-opening the bug. My previous patch has been reverted due
to the problems outlined in PR fortran/45005.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #38 from bernds at gcc dot gnu dot org 2010-07-21 22:48 ---
Subject: Bug 44970
Author: bernds
Date: Wed Jul 21 22:48:14 2010
New Revision: 162390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162390
Log:
PR bootstrap/44970
PR middle-end/45009
--- Comment #8 from bernds at gcc dot gnu dot org 2010-07-21 22:48 ---
Subject: Bug 45009
Author: bernds
Date: Wed Jul 21 22:48:14 2010
New Revision: 162390
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162390
Log:
PR bootstrap/44970
PR middle-end/45009
--- Comment #14 from kargl at gcc dot gnu dot org 2010-07-21 22:47 ---
Subject: Bug 44929
Author: kargl
Date: Wed Jul 21 22:47:36 2010
New Revision: 162389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162389
Log:
2010-07-21 Steven G. Kargl
PR fortran/44929
--- Comment #1 from sje at cup dot hp dot com 2010-07-21 22:39 ---
I backported the patch for PR 42869 to the 4.4 branch to fix Itanium.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45025
--- Comment #7 from sje at gcc dot gnu dot org 2010-07-21 22:38 ---
Subject: Bug 42869
Author: sje
Date: Wed Jul 21 22:37:53 2010
New Revision: 162387
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162387
Log:
2010-07-21 Steve Ellcey
PR target/42869
* config/
--- Comment #13 from kargl at gcc dot gnu dot org 2010-07-21 22:34 ---
Subject: Bug 44929
Author: kargl
Date: Wed Jul 21 22:34:07 2010
New Revision: 162386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162386
Log:
2010-07-21 Steven G. Kargl
PR fortran/44929
* Revert
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-21 22:23 ---
const int i; -fno-zero-initialized-in-bss -> .bss= FAIL
You need -fno-common also to get it out of the BSS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44690
--- Comment #7 from burnus at gcc dot gnu dot org 2010-07-21 22:08 ---
Close as fixed. I also do no longer see any valgrind errors.
BD, if you still see an ICE, please feel free to reopen this bug (or fill a new
one).
--
burnus at gcc dot gnu dot org changed:
What|Re
--- Comment #32 from paolo dot carlini at oracle dot com 2010-07-21 22:03
---
Ralf, do you have any opinion on Comment #31? Maybe Armand can try to produce a
patch (or alternate patches) and post to the mailing lists in order to make
sure knowledgeable people actually have a chance to s
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #1 from dodji at gcc dot gnu dot org 2010-07-21 21:54 ---
I am testing this patch:
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index ce35c91..bd3a97d 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -17585,9 +17585,11 @@ scope_die_for (tree t, dw_die_ref context_die)
--- 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
--- 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 #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 #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 #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 #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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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
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 #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
--
--- 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 #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 #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 #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 #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 #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
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 #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
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 #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
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 #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
--- 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 #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
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 #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
--- 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
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 #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
--- 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 #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 #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 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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):
--
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 #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
--- 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|
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 #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
1 - 100 of 132 matches
Mail list logo
