--- Comment #7 from roy dot 1rosen at gmail dot com 2010-07-15 06:52
---
Looks good now.
Thanks for the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
--- Comment #12 from burnus at gcc dot gnu dot org 2010-07-15 07:05 ---
Can you send the patch also to fortran@ and gcc-patc...@?
And can you fix the changelog by adding a line for io/transfer.c? It looks as
if you only changed the indenting, but I might be wrong.
The patch itself
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-15 07:17 ---
Fixed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-07-15 07:53 ---
Subject: Bug 40206
Author: jakub
Date: Thu Jul 15 07:52:51 2010
New Revision: 162209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162209
Log:
PR fortran/40206
* trans-stmt.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 08:00 ---
Works on x86_64 with -m32. Does the testcase work with GCC 4.4? Does it work
with the 4.5.0 release?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from graham dot gower at gmail dot com 2010-07-15 08:03
---
Works with 4.4.4. I can check 4.5 release tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-15 08:06 ---
Confirmed.
--
rguenth 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=44941
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-15 08:21 ---
Confirmed.
(gdb) call debug_gimple_stmt (stmt)
.MEM_12 = PHI .MEM_13(D)(2), (3)
we miss a PHI arg here after splitting the function.
func_4 (int p_5, unsigned char p_6, unsigned char p_7)
{
bb 2:
if (p_6_3(D)
At revision 162192, I get with -m32:
FAIL: gfortran.dg/char_array_structure_constructor.f90 -O3
-fomit-frame-pointer execution test
The failure is a Bus error with -O2 and -O3, and requires
-fomit-frame-pointer. Also the failure goes away when Revision 162148 was OK
and the test passes on
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 08:37 ---
Works with my pending set of patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
--
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=44945
This might be related to PR44941.
Command line:
$ gcc -O2 testcase.c
Output:
$ gcc -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:22:1: internal compiler error: in get_constraint_for_component_ref,
at tree-ssa-structalias.c:3184
Please submit a full bug report,
with preprocessed source
--- Comment #1 from zsojka at seznam dot cz 2010-07-15 09:00 ---
Created an attachment (id=21208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21208action=view)
reduced testcase (from wget sources)
Command line:
$ gcc -O2 pr44946.c
--
Hi all,
I have an interesting problem with gcc optimizing away an automatic variable
in a function which uses setjmp/longjmp in a macro-based exception processing
framework. Here's some example code (just to illustrate the problem, I haven't
tested this code):
#include stdlib.h
#include stdio.h
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it more readable
and messed up the auto variable name. Please use this code:
#include stdlib.h
#include stdio.h
#include setjmp.h
#define EXC_TRY 1
#define
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 09:18 ---
You need to mark auto variables that are life across setjmp/longjmp calls as
volatile.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On Jul 15, 2010, at 2:15 AM, cm1 at mumac dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it
more readable
and messed up the auto variable name. Please use this
--- Comment #3 from pinskia at gmail dot com 2010-07-15 09:19 ---
Subject: Re: Optimizer doesn't see setjmp()
On Jul 15, 2010, at 2:15 AM, cm1 at mumac dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I
Hi everybody!
Here is my problem : I wrote a c++ program on Linux which uses the pthread
library to handle several requests of several clients. Each request executes
an algo in which some parts, some loops, are parallelized with openmp (on 2
processors). I compile my program with gcc 4.3.
With
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 09:21 ---
Confirmed. It's mem-ref related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2010-07-15 09:37 ---
Subject: Re: [4.6 Regression] IPA-split
causes crash due to null pointer deref
(gdb) call debug_gimple_stmt (stmt)
.MEM_12 = PHI .MEM_13(D)(2), (3)
Hmm, I make no attempts to update alias info. Why return has
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-15 09:49 ---
Seems ix86_function_arg_advance ignores padding for 8 byte aligned arguments
when updating cum-words.
With:
#include stdarg.h
long double
test (int a, int b, int c, int d, int e, int f, int g, int g2, int g3, long
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 09:58 ---
It doesn't. It's a PHI node. So I suppose there was a CFG confluence
point here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44937
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 10:00 ---
CDDCE removes the single store in the loop but doesn't remove the virtual
PHI nodes. But you still have to deal with them I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44937
The gcc-bugs mailing list is for emails automatically generated by our
bug database, to report a bug please follow the instructions at
http://gcc.gnu.org/bugs/
However, your email doesn't seem to be a bug report and you don't give
enough information for a useful bug report, you haven't said what
--- Comment #4 from cm1 at mumac dot de 2010-07-15 10:14 ---
Thanks for the quick explanation and sorry for joining the club of submit
first, read the specs later folks -- I actually thought I knew them ;)
It makes of course sense to use volatile in the presence of setjmp/longjmp but
Ok, thanks for your answer.
I will try to simplify my code (several header and source files) to keep
only the part which produces the error, and I will post on the good forum
with more precisions on the problem.
Thanks.
--
View this message in context:
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 11:17 ---
Subject: Bug 44946
Author: rguenth
Date: Thu Jul 15 11:17:37 2010
New Revision: 162216
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162216
Log:
2010-07-15 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from hubicka at ucw dot cz 2010-07-15 11:31 ---
Subject: Re: [4.6 Regression] IPA-split
causes crash due to null pointer deref
CDDCE removes the single store in the loop but doesn't remove the virtual
PHI nodes. But you still have to deal with them I guess.
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-15 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-15 12:03 ---
Created an attachment (id=21209)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21209action=view)
gcc46-pr44942.patch
Untested fix. Grep tells me that cum-words is only ever used for x86-64
va_start expansion
With two sources:
struct A { long b[8] __attribute__((aligned (32))); };
void foo (long double, struct A);
int
main (void)
{
struct A a = { { 0, 1, 2, 3, 4, 5, 6, 7 } };
foo (8.0L, a);
return 0;
}
and:
struct A { long b[8] __attribute__((aligned (32))); };
void
foo (long double x, struct A
--- Comment #4 from domob at gcc dot gnu dot org 2010-07-15 12:24 ---
Subject: Bug 44709
Author: domob
Date: Thu Jul 15 12:23:47 2010
New Revision: 162219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162219
Log:
2010-07-15 Daniel Kraft d...@domob.eu
PR fortran/44709
--- Comment #5 from domob at gcc dot gnu dot org 2010-07-15 12:31 ---
Fixed the clean-up issues. Still remaining is the rejects-valid (2b) of
Tobias' original comment. I'll keep on with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44709
--- Comment #7 from uweigand at gcc dot gnu dot org 2010-07-15 12:38
---
Subject: Bug 44877
Author: uweigand
Date: Thu Jul 15 12:37:03 2010
New Revision: 162220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162220
Log:
PR target/44877
* config/spu/spu.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-15 13:11 ---
How should we align
struct A { long b[8] __attribute__((aligned (32))); };
when it is passed on stack?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-15 13:15 ---
If we want to be ABI compatible, I'm afraid it needs to be 16 byte aligned
only.
We don't align aligned(64) structs to 64 bytes either, even with -mavx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-07-15
13:19 ---
At -m32 on x86_64-apple-darwin10, the test cases which fail due to symbols
being optimized away include...
FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link,
-O2 -fwhopr
FAIL:
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-15 13:26 ---
Caller and call expander try to honor type alignment.
See PR 35771 and PR 35767. I think we should replace
BIGGEST_ALIGNMENT with MAX_STACK_ALIGNMENT.
--
hjl dot tools at gmail dot com changed:
What
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-15 13:33 ---
(In reply to comment #2)
If we want to be ABI compatible, I'm afraid it needs to be 16 byte aligned
only.
We don't align aligned(64) structs to 64 bytes either, even with -mavx.
That is because we couldn't
--- Comment #3 from janus at gcc dot gnu dot org 2010-07-15 13:36 ---
Subject: Bug 44936
Author: janus
Date: Thu Jul 15 13:36:28 2010
New Revision: 162221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162221
Log:
2010-07-15 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-15 13:42 ---
We have aligned double to 4 byte when passing on stack
in 32bit. I guess it is OK to use a smaller alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #4 from janus at gcc dot gnu dot org 2010-07-15 13:42 ---
Fixed with r162221. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-15 13:56 ---
When we pass 32byte aligned type on stack with 16byte
alignment, do we mark it as 16byte aligned or 32byte
aligned?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-15 14:10 ---
For 32bit, we should align it to 4 byte.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
This is about both C and C++.
gcc warns about a construction like i2==0, and this helped us find bugs. But
we noticed, in the same code, occurrences of: i=2==0. This code suffers from
the same problem, but gcc doesn't warn about it. Would it be a good idea to
extend the warning to this case?
--
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-15 14:38 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-15 14:37 ---
0x000adddc in __gfortran_compare_string (len1=4, s1=0x0, len2=4, s2=0x1f40
s1 should not be NULL but the value of c%a. The question is why does this
fail now. Recently added were: PURE and the fn spec of ..R.R.
j...@evans:/abuild/jh/build-mozilla-debug/js/src/shell
/abuild/jh/trunk-install/bin/g++ -fwhopr=24 -fuse-linker-plugin -fpermissive
-o js.o -c -I../../../dist/system_wrappers_js -include
/abuild/jh/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\Linux2.6.32.12-0\
--- Comment #9 from jakub at gcc dot gnu dot org 2010-07-15 15:09 ---
Should be fixed now for 4.6+.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
j...@evans:/abuild/jh/build-mozilla-debug/toolkit/crashreporter/google-breakpad/src/common/dwarf
/abuild/jh/trunk-install/bin/g++ -fwhopr=24 -fuse-linker-plugin -fpermissive
-funsigned-char host_bytereader.ii -c
--- Comment #3 from zsojka at seznam dot cz 2010-07-15 15:16 ---
Created an attachment (id=21210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21210action=view)
different testcase, reduced
$ gcc -O2 -finline-functions testcase.c
testcase.c:37:1: error: caller edge frequency 1142
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-15 15:17 ---
Created an attachment (id=21211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21211action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44951
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-15 15:22 ---
Created an attachment (id=21212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21212action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44950
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-15 15:23 ---
Created an attachment (id=21213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21213action=view)
dump with -m32 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #3 from dominiq at lps dot ens dot fr 2010-07-15 15:24 ---
Created an attachment (id=21214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21214action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-15 15:27 ---
Created an attachment (id=21215)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21215action=view)
dump with -m64 -O2 -fomit-frame-pointer -fdump-tree-optimized
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-15 15:47 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
#include iostream
evans:/abuild/jh/trunk-install/bin/:[0]# ./g++ -O2 g.C -S
evans:/abuild/jh/trunk-install/bin/:[0]# more g.s
.file g.C
.text
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-15 16:02 ---
(In reply to comment #3)
Caller and call expander try to honor type alignment.
See PR 35771 and PR 35767. I think we should replace
BIGGEST_ALIGNMENT with MAX_STACK_ALIGNMENT.
The call expander should not look
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-15 16:02 ---
According to gcc-testresults this seems to affect only Darwin, cf.
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01432.html
The optimized dumps also seem to be OK (or at there is no obvious difference).
In the
This is expected and iirc required by the c++ standard too.
On Jul 15, 2010, at 8:51 AM, hubicka at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
Noticed while reading
http://comments.gmane.org/gmane.comp.web.chromium.devel/16789
evans:/abuild/jh/trunk-install/bin/:[0]# more g.C
--- Comment #1 from pinskia at gmail dot com 2010-07-15 16:02 ---
Subject: Re: New: #include iostream.h imply global constructor.
This is expected and iirc required by the c++ standard too.
On Jul 15, 2010, at 8:51 AM, hubicka at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-15 16:03 ---
Why's this not in libstdc++.so .init?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2010-07-15 16:05 ---
How about this patch?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4fd2aab..65e13a3 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -6594,8 +6594,8 @@
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-07-15 16:12 ---
... and are we required to emit the constructor even if we know var is not
used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #10 from hjl dot tools at gmail dot com 2010-07-15 16:20
---
Created an attachment (id=21216)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21216action=view)
A patch
I am testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-15 16:25 ---
a) _gfortran_compare_string is now PURE,
http://gcc.gnu.org/viewcvs?view=revisionrevision=162160
The test passes with the following patch:
--- ../_clean/gcc/fortran/trans-decl.c 2010-07-15 18:05:19.0
--- Comment #11 from jakub at gcc dot gnu dot org 2010-07-15 16:28 ---
That is going to break the ABI a lot. You'd e.g. change long double passing
for -m64.
What you IMHO want is to do what the code currently does, and if the alignment
after that is 32 bytes, use a predicate similar to
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-15 16:30 ---
(In reply to comment #2)
Why's this not in libstdc++.so .init?
because this will not work if libstdc++ is a static library.
Take:
#include iostream
namespace {
struct g
{
g(){ std::cout t; }
};
g one;
}
---
gfortran.dg/char4_iunit_1.f03 fails on powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg01445.html ).
It looks like an endianess issue.
--
Summary: FAIL: gfortran.dg/char4_iunit_1.f03 * execution test
Product: gcc
Version: 4.6.0
--- Comment #5 from redi at gcc dot gnu dot org 2010-07-15 16:38 ---
This is why you should only include iostream if you want actually want
std::cin, std::cout or std::cerr (or the wide character equivalents.)
Otherwise you should only include one or more of iosfwd, istream and
ostream,
--- Comment #12 from hjl dot tools at gmail dot com 2010-07-15 16:41
---
Created an attachment (id=21217)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21217action=view)
A new patch
How about this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
--- Comment #6 from redi at gcc dot gnu dot org 2010-07-15 16:45 ---
and please ... it's 2010, iostream not iostream.h ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
--- Comment #13 from hjl dot tools at gmail dot com 2010-07-15 16:47
---
struct A {
long b[8] __attribute__((aligned (32)));
__m128i x;
};
What alignment should we use to pass it on stack?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948
I believe this is related to Bug #43493
I cannot catch exceptions if a variable (non-static) is use for the message...
Using the following program:
#include cstdlib
#include iostream
#include sstream
#include stdexcept
#include string
using namespace std;
void generateException(int
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-07-15 16:53 ---
Hehe, I am really not C++ guy even in 2010, but I have impression that people
are including iostream without really thinking about consequences here.
Well, so what we can do about the startup times then? I will
--- Comment #1 from redi at gcc dot gnu dot org 2010-07-15 16:53 ---
(In reply to comment #0)
However, when I compile with gcc 4.3 or 4.4 installed with macports 1.9.1 I
get:
How is that gcc configured?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44954
--- Comment #2 from mwglass at sandia dot gov 2010-07-15 16:56 ---
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.4/configure --prefix=/opt/local
--build=x86_64-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,java,fortran
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-07-15 16:57 ---
IIRC this is a bug in Apple's unwinder.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44954
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-07-15 16:57
---
*** Bug 44954 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-15 16:57 ---
*** This bug has been marked as a duplicate of 42159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-07-15 16:58 ---
*** This bug has been marked as a duplicate of 42159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-07-15 16:58
---
*** Bug 43277 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-07-15 16:58 ---
*** This bug has been marked as a duplicate of 42159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pinskia at gcc dot gnu dot org 2010-07-15 16:58
---
*** Bug 43493 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from redi at gcc dot gnu dot org 2010-07-15 17:03 ---
I wonder if some of the dups are actually caused by not building gcc with
--enable-fully-dynamic-string which is needed on Snow Leopard, but wasn't done
by macports until recently:
While I am working on prefetching-incurred performance degradation on
168.wupwise, I find that complex arrays are always over-prefetched.
Prefetches are generated for both the real part and imagine part.
subroutine s311 (i,j,n,m,beta,a,b)
c
c reductions
c sum reduction
c
When using templates, AAI::f should not be reachable from main() because it
is protected.
The correct behavior is observed in the template-less version: the compiler
detects an encapsulation error.
% cat foo.cpp
#if NO_TEMPLATES == 1
class A { protected: int f() { return 42; } };
class B : public
--- Comment #1 from changpeng dot fang at amd dot com 2010-07-15 17:20
---
This is a piece of code that shows the two prefetches for b.
mulss %xmm4, %xmm5
addq$8, %rdx
prefetcht0 96(%r11)
prefetcht0 100(%r11)
subss %xmm2, %xmm1
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-15 17:21 ---
This has been at least fixed in 4.5.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44956
When compiling a generic procedure, the generic name is not entered in the
symbol table, which then causes subsequent 'use' statements to fail.
Example:
in m_die.F90 we declare:
module m_die
use m_mpif90, only : MP_perr
implicit none
private ! except
public :: die
--- Comment #2 from redi at gcc dot gnu dot org 2010-07-15 17:39 ---
fixed in 4.4.3 as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44956
--- Comment #2 from rakdver at kam dot mff dot cuni dot cz 2010-07-15
17:44 ---
Subject: Re: over-prefetched for arrays of
complex number
This is a piece of code that shows the two prefetches for b.
mulss %xmm4, %xmm5
addq$8, %rdx
--- Comment #1 from kargl at gcc dot gnu dot org 2010-07-15 17:48 ---
(In reply to comment #0)
When compiling a generic procedure, the generic name is not entered in the
symbol table, which then causes subsequent 'use' statements to fail.
Example:
in m_die.F90 we declare:
--- Comment #8 from redi at gcc dot gnu dot org 2010-07-15 17:49 ---
(In reply to comment #7)
Hehe, I am really not C++ guy even in 2010, but I have impression that people
are including iostream without really thinking about consequences here.
Yes, and in many cases that's the
--- Comment #9 from paolo dot carlini at oracle dot com 2010-07-15 18:26
---
Let's say we remove that horrible .h from the Summary, since, to be fair,
didn't exist in g.C in the first place ;)
That said, I agree with Jon, by and large, with the following minor additional
observations:
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-15 18:55 ---
Created an attachment (id=21218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21218action=view)
assembly generated with -S -m32 -O2 -fomit-frame-pointer -fverbose-asm
The original file has been modified to
--- Comment #14 from hjl dot tools at gmail dot com 2010-07-15 19:07
---
(In reply to comment #13)
struct A {
long b[8] __attribute__((aligned (32)));
__m128i x;
};
What alignment should we use to pass it on stack?
I think when such a struct is passed on stack, the
1 - 100 of 137 matches
Mail list logo
