--
photon at seznam dot cz changed:
What|Removed |Added
Severity|enhancement |normal
Summary|-Wconversion: do not warn |-Wconversion generate
--- 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 t
--- 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=18203&action=view)
preprocessed version of the file mpn_exp.c from mpfr-2.4.1
Note that replacing line 74:
MPN_ZERO (a, n - 1);
b
--- 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=18203&action=view) [edit]
> preprocessed version of the file mpn_exp.c from mpfr-2.4.1
>
> Note that replaci
--- 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 cd[10
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-16 09:44 ---
The middle-end presents the vectorizer with
:
# i_13 = PHI
# ivtmp.26_8 = PHI
D.1623_3 = xd[i_13];
sincostmp.21_1 = __builtin_cexpi (D.1623_3);
D.1624_4 = IMAGPART_EXPR ;
sd[i_13] = D.1624_4;
D.1625_
--- 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=18204&action=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 Confirm
--- 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
--- 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 inste
--- 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.
kir...@t2:[/tmp
--- 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 ---
> pr407
--- 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=18205&action=view)
preprocessed source
Includes contents of headers ,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40771
--- 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) (GCC)
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=18206&action=view)
preprocessed source of test code
Runs 1 << 24 iterations, prints average time in ticks.
--
http://gcc.gnu.org/bug
--- 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.
--
http://gcc
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 enou
--- 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=18207&action=view)
modules definition file, bzip2'd
cat bigmod.f90.bz2 | bunzip2 > bigmod.f90
compressed to avoid bugzilla size limita
--- 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=18208&action=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
-B/home/joel/test-gcc
/home/joel/test-gcc/b-gcc1-m32c/./gcc/xgcc
-B/home/joel/test-gcc/b-gcc1-m32c/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-gcc1-m32c/m32c-rtems4.10/newlib/ -isystem
/home/joel/test-gcc/b-gcc1-m32c/m32c-rtems4.10/newlib/targ-include -isystem
/home/joel/test-gcc/gcc-svn/newlib/libc/include
-B/home/joel/te
--- 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=18209&action=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)
>
--- 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 s
--- 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.
--
http://gcc.
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
--- 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:
> > real
--- 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=gcc&view=rev&rev=149721
Log:
PR libstdc++/37907
Support std::is_standard_layou
--- 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=18210&action=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=18211&action=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 the
--- 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 d
--- 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 ve
--- 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
Status|AS
--- 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
Status|ASS
--- 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=gcc&view=rev&rev=149722
Log:
2009-07-17 Aldy Hernandez
Manuel López-Ibáñez
--- 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 specifie
template
struct A
{
typedef T2 (T1::*m) (T3);
A (m) {}
};
struct B;
struct C
{
void foo (B *);
};
typedef A 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 'void __static_initialization_and_destruction_0(in
--- 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'
../../src-trunk
--- 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=gcc&view=rev&rev=149733
Log:
2009-07-16 H.J. Lu
PR bootstrap/40781
* builtins.
--- 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
--- 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/
--- Comment #4 from rob1weld at aol dot com 2009-07-17 06:43 ---
(In reply to comment #2)
> Confirmed. The proposed fix is not correct, though, as the type of the first
> argument to munmap _is_ void* according to POSIX.
Thanks for applying the patch. I've not looked at 'LTO' source in
We are building c code with compiler optimization. We are using GCC 4.1.2 as
cross compiler for ARM 11 MP core. Here is description of the problem as I can
not share the actual code due to licensing issues
function A -> function B. Function A calls B with a pointer as an argument.
When a function
Compile the following code with options -Os -mthumb -march=armv5te
union FloatIntUnion {
float fFloat;
int fSignBitInt;
};
static inline float fast_inc(float x) {
union FloatIntUnion data;
data.fFloat = x;
data.fSignBitInt += 1;
return data.fFloat;
}
exte
--- Comment #1 from carrot at google dot com 2009-07-17 06:56 ---
Created an attachment (id=18212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18212&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40783
73 matches
Mail list logo
