--- Comment #10 from ubizjak at gmail dot com 2009-07-16 06:56 ---
(In reply to comment #6)
Thus with the GLIBC (with AMD patches) or with the AMCL, one gets only a
slowdown of 25%, which is still acceptable. Why the Intel routines are so slow
on my AMD, I do not know.
See [1],
--
photon at seznam dot cz changed:
What|Removed |Added
Severity|enhancement |normal
Summary|-Wconversion: do not warn |-Wconversion
--- Comment #11 from ubizjak at gmail dot com 2009-07-16 07:16 ---
(In reply to comment #6)
Thus the question is really: Why are neither vmlsSinCos4 nor vmlsTan4 - nor
for
ACML vrs4_sincosf/vrsa_sincosf (vrs*_tan* does not exist) called?
Because sincos returns _TWO_ values and the
--- Comment #5 from zimmerma+gcc at loria dot fr 2009-07-16 07:52 ---
Created an attachment (id=18203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18203action=view)
preprocessed version of the file mpn_exp.c from mpfr-2.4.1
Note that replacing line 74:
MPN_ZERO (a, n - 1);
--- Comment #6 from mikpe at it dot uu dot se 2009-07-16 08:31 ---
(In reply to comment #5)
Created an attachment (id=18203)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18203action=view) [edit]
preprocessed version of the file mpn_exp.c from mpfr-2.4.1
Note that replacing
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-16 09:06
---
Actually the middle-end presents the vectorizer with a call to a complex
function and REAL/IMAGPART exprs. I don't remember exactly which part
confuses it, but certainly the mixed complex / real types do.
--
The following should be vectorized with proper -mveclib:
float xf[1024];
float sf[1024];
float cf[1024];
void foo (void)
{
int i;
for (i = 0; i 1024; ++i)
{
sf[i] = __builtin_sinf (xf[i]);
cf[i] = __builtin_cosf (xf[i]);
}
}
double xd[1024];
double sd[1024];
double
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-16 09:44 ---
The middle-end presents the vectorizer with
bb 3:
# i_13 = PHI i_7(4), 0(2)
# ivtmp.26_8 = PHI ivtmp.26_16(4), 1024(2)
D.1623_3 = xd[i_13];
sincostmp.21_1 = __builtin_cexpi (D.1623_3);
D.1624_4 =
--- Comment #4 from vielhaber at gmail dot com 2009-07-16 09:59 ---
Created an attachment (id=18204)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18204action=view)
g++ -version
--
vielhaber at gmail dot com changed:
What|Removed |Added
--- Comment #5 from vielhaber at gmail dot com 2009-07-16 10:01 ---
It was an index out of range error. Now, -O0 and -O3 both work as expected.
--
vielhaber at gmail dot com changed:
What|Removed |Added
--
ubizjak at gmail dot com changed:
What|Removed |Added
BugsThisDependsOn||40770
Status|UNCONFIRMED |NEW
Ever
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-16 09:43 ---
See PR 40770 for Vectorization of complex types, vectorization of sincos
missing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #7 from david dot kirkby at onetel dot net 2009-07-16 10:19
---
(In reply to comment #4)
mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running
sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0,
and
4.4.1 20090630.
I don't have
--- Comment #8 from david dot kirkby at onetel dot net 2009-07-16 10:24
---
(In reply to comment #4)
Sounds a lot like PR39867 and PR40747 are hitting you. Can you grab those
fixes, apply them to your 4.4.0, rebuild it, and test mpfr again? Or get the
4.4.1-RC and test that
--- Comment #9 from jakub at gcc dot gnu dot org 2009-07-16 10:31 ---
folding happens even at -O0 and both bugs are in the folder. So, please try
ftp://sources.redhat.com/pub/gcc/snapshots/4.4.1-RC-20090715/
first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #2 from irar at il dot ibm dot com 2009-07-16 12:29 ---
pr40770.c:20: note: == examining statement: sincostmp.21_1 = __builtin_cexpi
(D.1625_3);
pr40770.c:20: note: get vectype for scalar type: complex double
pr40770.c:20: note: not vectorized: unsupported data-type complex
--- Comment #10 from david dot kirkby at onetel dot net 2009-07-16 12:32
---
(In reply to comment #9)
folding happens even at -O0 and both bugs are in the folder. So, please try
ftp://sources.redhat.com/pub/gcc/snapshots/4.4.1-RC-20090715/
first.
I tried it.
--- Comment #3 from rguenther at suse dot de 2009-07-16 13:05 ---
Subject: Re: Vectorization of complex types,
vectorization of sincos missing
On Thu, 16 Jul 2009, irar at il dot ibm dot com wrote:
--- Comment #2 from irar at il dot ibm dot com 2009-07-16 12:29 ---
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-16 13:32 ---
(In reply to comment #3)
Yes - there is no vector type for complex double. But the vectorizer
could query for a vector type for the complex component type (double)
and divide the vector element count by 2 (for
--- Comment #5 from rguenther at suse dot de 2009-07-16 13:57 ---
Subject: Re: Vectorization of complex types,
vectorization of sincos missing
On Thu, 16 Jul 2009, burnus at gcc dot gnu dot org wrote:
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-16 13:32
---
--- Comment #11 from jakub at gcc dot gnu dot org 2009-07-16 14:07 ---
You haven't mentioned what options you compiled this file with. So, assuming
-O2, I see:
add %i4, -1, %l5! n,, tmp186
sethi %hi(1073740800), %o2!, tmp189
sll %l5, 2, %l5
For the following code:
---
uint8_t data[16];
static __attribute__((noinline)) void test(unsigned i)
{
unsigned j;
for (j = 0; j 16; j++)
data[j] = (i + j) 8;
}
---
code generated with -O3 -ftree-vectorize is ~25%
--- Comment #1 from zsojka at seznam dot cz 2009-07-16 15:06 ---
Created an attachment (id=18205)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18205action=view)
preprocessed source
Includes contents of headers stdint.h, stdio.h
--
--- Comment #2 from zsojka at seznam dot cz 2009-07-16 15:06 ---
# ./gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk/build/
Thread model: posix
gcc version 4.5.0 20090714 (experimental)
For the following code:
uint8_t data[16];
static __attribute__((noinline)) void test(unsigned i)
{
unsigned j;
for (j = 0; j 16; j++)
data[j] = ((i + j) 0xFF00) 8;
}
--- Comment #1 from zsojka at seznam dot cz 2009-07-16 15:34 ---
Created an attachment (id=18206)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18206action=view)
preprocessed source of test code
Runs 1 24 iterations, prints average time in ticks.
--
--- Comment #2 from zsojka at seznam dot cz 2009-07-16 15:42 ---
When
data[j] = ((i + j) 0xFF00) 8;
is replaced by
data[j] = (i + j) 8;
generated asm uses shr eax, 8 instead of movzx eax, ah, and runs in 19
ticks in average.
--
On linux x86, with -m32 or -m64,
gfortran 4.4.0 exhausts over 2GB of swap space compiling the attached source
file
at -O3.In contrast 4.1.2 compiles unexceptionally. This might be
expected behavior of 4.4.0 due to some new laborious optimization, which
would terminate eventually with
--- Comment #1 from dh458 at oakapple dot net 2009-07-16 16:16 ---
Created an attachment (id=18207)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18207action=view)
modules definition file, bzip2'd
cat bigmod.f90.bz2 | bunzip2 bigmod.f90
compressed to avoid bugzilla size
--- Comment #2 from dh458 at oakapple dot net 2009-07-16 16:17 ---
Created an attachment (id=18208)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18208action=view)
failing source file that uses modules in bigmod.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40773
/home/joel/test-gcc/b-gcc2-arm/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc2-arm/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc2-arm/arm-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc2-arm/arm-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-16 17:02 ---
Created an attachment (id=18209)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18209action=view)
Test case (preprocessed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40776
--- Comment #2 from joel at gcc dot gnu dot org 2009-07-16 17:03 ---
/home/joel/test-gcc/b-gcc1-m32c/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-m32c/./gcc/ -c j.c -mcpu=m32cm -O0
Works.. ICE at -O1 and -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40776
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -I.. -I. -Iada
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-07-16 17:08 ---
*** Bug 40776 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-16 17:08 ---
*** This bug has been marked as a duplicate of 39182 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2009-07-16 17:22 ---
Does it compile with either -O or -O2? gfortran 4.4.0 may be trying
to do more inlining, which can consume more memory for temporary
arrays.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40773
--- Comment #6 from irar at il dot ibm dot com 2009-07-16 17:31 ---
(In reply to comment #3)
make_vector_type returns NULL for this type.
Yes - there is no vector type for complex double. But the vectorizer
could query for a vector type for the complex component type (double)
and
--- Comment #4 from dh458 at oakapple dot net 2009-07-16 18:24 ---
Compiles OK at -O2, but more slowly than with 4.1.2:
4.1.2 4.4.0
-O2:
real1m19.827s real2m58.945s
-O3:
real1m30.645s real 10m5.166s
Even if -O3 ultimately generates correct code in
--- Comment #10 from mikpe at it dot uu dot se 2009-07-16 18:33 ---
More memory usage numbers on this test case:
With 4.4.1-RC-20090715: i686 peaks at 616M, powerpc at 799M, and arm at 1211M.
With 4.5.0-20090709: i686 peaks at 530M, powerpc at 707M, and arm at 933M.
--
Cloned functions appear not to be properly instrumented by mudflap e.g alloca
is not instrumented.
This is responsible for the recent regressions in libmudflap testsuite.
(pass45-frag.c,fail31-frag.c)
--
Summary: [4.5 Regression] Mudflap instrumentation missing in
--- Comment #1 from tjruwase at google dot com 2009-07-16 19:24 ---
The problem is that mudflap avoids instrumenting synthetic functions, i.e
DECL_ARTIFICIAL(decl) . Since cloned functions are synthetic functions, they
are
not instrumented by the 2nd mudflap pass.
A possible fix would
--- Comment #5 from kargl at gcc dot gnu dot org 2009-07-16 19:55 ---
(In reply to comment #4)
Compiles OK at -O2, but more slowly than with 4.1.2:
4.1.2 4.4.0
-O2:
real1m19.827s real2m58.945s
-O3:
real1m30.645s real 10m5.166s
Even if -O3
--- Comment #6 from kargl at gcc dot gnu dot org 2009-07-16 20:29 ---
(In reply to comment #5)
(In reply to comment #4)
Compiles OK at -O2, but more slowly than with 4.1.2:
4.1.2 4.4.0
-O2:
real1m19.827s real2m58.945s
-O3:
real1m30.645s
--- Comment #12 from marc dot glisse at normalesup dot org 2009-07-16
20:34 ---
(In reply to comment #11)
for this memset call, which looks correct to me. The st %g1, [%i0+%l5] line
stores to %i0 a[n-1] and memset is called with memset (a, 0, (n + 0x3fffU)
2); So, if this
--- Comment #3 from jason at gcc dot gnu dot org 2009-07-16 20:36 ---
Subject: Bug 37907
Author: jason
Date: Thu Jul 16 20:36:10 2009
New Revision: 149721
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149721
Log:
PR libstdc++/37907
Support std::is_standard_layout
--- Comment #13 from heydowns at borg dot com 2009-07-16 21:11 ---
Created an attachment (id=18210)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18210action=view)
Fix updated for gcc 4.4.0, link xpg6 for c++, and link xpg4 for gnu*
Updated patch against gcc 4.4.0.
Also add xpg6
--- Comment #14 from js-gcc at webkeks dot org 2009-07-16 21:16 ---
Any comments? This is still very annoying and completely killing the ability to
have plugins/bundles on win32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
--- Comment #1 from jkt at mailsnare dot net 2009-07-16 21:23 ---
Created an attachment (id=18211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18211action=view)
patch for basic_string::_M_disjunct corner case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40779
--- Comment #2 from jkt at mailsnare dot net 2009-07-16 21:27 ---
correction:
_M_disjunct should return false because the source and target are conjunct
(overlap).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40779
--- Comment #13 from david dot kirkby at onetel dot net 2009-07-16 21:29
---
(In reply to comment #11)
You haven't mentioned what options you compiled this file with. So, assuming
-O2, I see:
add %i4, -1, %l5! n,, tmp186
sethi %hi(1073740800), %o2!,
i found a corner case, definitely odd but legal, in basic_string::_M_disjunct.
consider the following:
string s1(abcd);
string s2(s1); // make it shared
s1.append(s.data() - 1, 5);
_M_disjunct should return true but, because it does not check the length,
fails.
i created a patch for this but
--- Comment #8 from paolo dot carlini at oracle dot com 2009-07-16 21:46
---
Jason, I think it's the right time to revisit this PR: after your patch the
testcase passes unconditionally. I'm just wondering if it would make sense to
have a different semantics for __is_pod depending on
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-16 22:01
---
s1.append(s.data() - 1, 5);
What's s? If, as I believe, it's a std::basic_string - s1, s2, whatever - on
which you are calling the data member function, the line is definitely illegal,
because s.data() - 1
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-16 22:06
---
... probably not, if you ask me. We briefly discussed the issue today, in
relation to the builtins of the same name as provided by other front-ends. We
never tried implementing the exact C++03 semantics: the
--- Comment #10 from jason at gcc dot gnu dot org 2009-07-16 22:09 ---
Fixed for 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2009-07-16 22:11 ---
Fixed for 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from manu at gcc dot gnu dot org 2009-07-16 22:30 ---
Subject: Bug 40435
Author: manu
Date: Thu Jul 16 22:29:52 2009
New Revision: 149722
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149722
Log:
2009-07-17 Aldy Hernandez al...@redhat.com
Manuel
--- Comment #10 from manu at gcc dot gnu dot org 2009-07-16 22:38 ---
FIXED.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from kargl at gcc dot gnu dot org 2009-07-16 22:47 ---
Further investigation suggests that -O3 is unusable with Fortran code
when the size of the code in a single file or module becomes very large.
Specifically, gcc.info states:
'-O3' turns on all optimizations
template class T1, typename T2, typename T3
struct A
{
typedef T2 (T1::*m) (T3);
A (m) {}
};
struct B;
struct C
{
void foo (B *);
};
typedef A C, void, B * D;
typedef void (C::*E) (B *);
struct F;
typedef void (C::*G) (F);
D d ((E) (G) C::foo);
ICEs with -m32:
rh511229.ii: In function
--- Comment #1 from jakub at gcc dot gnu dot org 2009-07-17 00:08 ---
r140145 in particular.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40780
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-17 00:28 ---
This appears to be more than a fortran issue. I've changed
the component to tree-optimization out lack of a better choice.
--
kargl at gcc dot gnu dot org changed:
What|Removed
On Linux/ia64, revision 149722:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00603.html
failed to bootstrap:
cc1: warnings being treated as errors
../../src-trunk/gcc/builtins.c: In function 'expand_builtin_memcmp':
../../src-trunk/gcc/builtins.c:4171:14: error: unused variable 'loc'
--- Comment #14 from zimmerma+gcc at loria dot fr 2009-07-17 00:57 ---
You haven't mentioned what options you compiled this file with.
the problem appears both with -O0, -O1 and -O2.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #1 from hjl at gcc dot gnu dot org 2009-07-17 01:04 ---
Subject: Bug 40781
Author: hjl
Date: Fri Jul 17 01:03:55 2009
New Revision: 149733
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149733
Log:
2009-07-16 H.J. Lu hongjiu...@intel.com
PR bootstrap/40781
--- Comment #15 from david dot kirkby at onetel dot net 2009-07-17 03:21
---
(In reply to comment #14)
You haven't mentioned what options you compiled this file with.
the problem appears both with -O0, -O1 and -O2.
Paul
Also worth noting is that this builds fine with some
--- Comment #16 from david dot kirkby at onetel dot net 2009-07-17 04:11
---
(In reply to comment #0)
See http://websympa.loria.fr/wwsympa/arc/mpfr/2009-07/msg00031.html
and the following discussion.
This was on t2.math.washington.edu with
/usr/local/gcc-4.4.0-sun-linker/bin/gcc:
69 matches
Mail list logo
