http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471
Bug #: 53471
Summary: [4.8 LTO] ICE in pp_base_format, at pretty-print.c:510
(-flto -g)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470
Bug #: 53470
Summary: [4.8 LTO] ICE when linking with -g in
splice_child_die, at dwarf2out.c:4264
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426
--- Comment #14 from vincenzo Innocente
2012-05-23 11:53:13 UTC ---
fix confirmed
trunk revision 187799
compiles again my large application
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373
--- Comment #12 from vincenzo Innocente
2012-05-23 09:18:02 UTC ---
gcc build for me with -march=native equivalent to -march=bdver1 (and therefore
-mavx)
with the "latest" trunk revision 187789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #8 from vincenzo Innocente
2012-05-23 09:01:33 UTC ---
works with
/lib64/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
Compiled by GNU CC version 4.4.6 20110731 (Red Hat 4.4.6-3).
Compiled on a Linux 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426
--- Comment #11 from vincenzo Innocente
2012-05-23 08:03:54 UTC ---
sorry I cannot test the patch on the original failing files as at revision
187789 I get
cat > ipa.patch
--- tree-ssa-structalias.c (revision 187695)
+++ tree-ssa-structalias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
--- Comment #7 from vincenzo Innocente
2012-05-22 13:42:17 UTC ---
mine is a one-year-old libc
GNU C Library stable release version 2.13, by Roland McGrath et al.
….
Compiled by GNU CC version 4.6.1 20110520 (prerelease).
Compiled on a Linux 2.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53451
vincenzo Innocente changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #2 from vincenzo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450
vincenzo Innocente changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53433
vincenzo Innocente changed:
What|Removed |Added
CC||vincenzo.innocente at cern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53451
Bug #: 53451
Summary: [4.8 regression] ICE verify_gimple failed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53450
Bug #: 53450
Summary: [4.8 Regression] ICE in compiling
libiberty/cp-demangle.c with -O2
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449
Bug #: 53449
Summary: [4.8 regression] fortran fails to build
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53432
Bug #: 53432
Summary: [4.8] ICE failed to reclaim unneeded function in same
comdat group
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53426
vincenzo Innocente changed:
What|Removed |Added
Known to work||4.7.1
Summary|[lto]:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373
--- Comment #7 from vincenzo Innocente
2012-05-20 17:10:36 UTC ---
revision 187695 does not solve PR53393
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49616
vincenzo Innocente changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53393
Bug #: 53393
Summary: [4.8] ICE in building gcc ( in in
save_call_clobbered_regs () at
../../gcc-trunk/gcc/caller-save.c:876)
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337
--- Comment #4 from vincenzo Innocente
2012-05-15 10:19:29 UTC ---
tested with latest binutil
no change (but nicer error message)
GNU gold (GNU Binutils 2.22.52.20120515) 1.11
/tmp/innocent/ccIKFOKY.ltrans1.ltrans.o:ccIKFOKY.ltrans1.o:function v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337
--- Comment #3 from vincenzo Innocente
2012-05-14 14:08:04 UTC ---
I will try the trunk go binutils.
Still I confirm that this warning does not appear at all (in real-life code,
not just in the attached test case) with gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #34 from vincenzo Innocente
2012-05-14 07:41:02 UTC ---
I've created PR53337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337
--- Comment #1 from vincenzo Innocente
2012-05-14 07:39:45 UTC ---
Created attachment 27397
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27397
preprocessed file (for those not having boost)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53337
Bug #: 53337
Summary: [4.7.1 lto] produces warning: relocation refers to
discarded section in linker (gold, binutil 2.22)
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53335
vincenzo Innocente changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53335
Bug #: 53335
Summary: [4.6,4.7,4.8] pragma visibility(hidden) propagates
beyond pop
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #32 from vincenzo Innocente
2012-05-10 17:13:20 UTC ---
On 10 May, 2012, at 7:07 PM, hubicka at ucw dot cz wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
>
> --- Comment #31 from Jan Hubicka 2012-05-10 17:07:47
> UTC -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #19 from vincenzo Innocente
2012-05-10 16:51:33 UTC ---
On 10 May, 2012, at 6:48 PM, tmsriram at google dot com wrote:
>> As you notice the source code is identical as I'm exploiting compiler
>> autovectorization here.
>> In this cas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #30 from vincenzo Innocente
2012-05-10 15:50:15 UTC ---
using the new binutil I've no more error
still warning of the type
tmp/innocent/ccmPaLCz.ltrans6.ltrans.o:ccmPaLCz.ltrans6.o:function
_ZTVN5boost16exception_detail10clone_implINS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #17 from vincenzo Innocente
2012-05-10 10:16:13 UTC ---
I tested this
float x[1024], y[1024], z[1024], w[1024];
void foo() {
for (int i=0; i!=1024; ++i)
x[i]=y[i]*z[i]+w[i];
}
void __attribute__ ((target("arch=corei7"))) fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #17 from vincenzo Innocente
2012-05-10 09:55:42 UTC ---
I managed to get the linker-plugin enabled
1) building gcc in a directory different than the svn source one
2) using
--with-build-time-tools=
to point where we have all "current"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #29 from vincenzo Innocente
2012-05-10 07:53:37 UTC ---
we will try binutil 2.22
in any case the test case is simple (with boost 1.49)
notice how w/o linker-plugin NO symbol at all are generated for
boost::exception_detail::clone_imp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
vincenzo Innocente changed:
What|Removed |Added
CC||vincenzo.innocente at cern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
vincenzo Innocente changed:
What|Removed |Added
Summary|lto and |[lto w/o linker plugin]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #15 from vincenzo Innocente
2012-05-09 14:48:20 UTC ---
I'm indeed using a "ld" that is not the one of the system.
googling around I found this:
http://comments.gmane.org/gmane.comp.gcc.help/41304
titled" g++: error: -fuse-linker-plu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423
--- Comment #11 from vincenzo Innocente
2012-05-09 13:16:30 UTC ---
I found the reference in the binutil bugzilla
http://sourceware.org/bugzilla/show_bug.cgi?id=12629
was fixed by Ian in gold on 2011-06-30.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #13 from vincenzo Innocente
2012-05-09 12:35:51 UTC ---
On 9 May, 2012, at 2:21 PM, hubicka at ucw dot cz wrote:
> No, LTO plugin is needed for "proper" LTO and will always be. We have
> alternative
> non-plugin path that results in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #11 from vincenzo Innocente
2012-05-09 10:47:02 UTC ---
if I add -fuse-linker-plugin I get
c++: error: -fuse-linker-plugin is not supported in this configuration
my understanding was that since 4.6 linker-plugin was not required anym
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #10 from vincenzo Innocente
2012-05-09 10:40:08 UTC ---
On 9 May, 2012, at 12:15 PM, rguenth at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
>
> --- Comment #9 from Richard Guenther 2012-05-09
> 10:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #8 from vincenzo Innocente
2012-05-09 10:03:33 UTC ---
On 9 May, 2012, at 11:58 AM, rguenth at gcc dot gnu.org wrote:
> Ok, so the question would be - why does GCC think this symbol is not
> possibly referenced from outside of the LT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #6 from vincenzo Innocente
2012-05-09 09:39:54 UTC ---
On 9 May, 2012, at 11:10 AM, rguenth at gcc dot gnu.org wrote:
> All hidden symbols are postfixed with something like .local.77.4195, making
> them no longer the symbols for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #4 from vincenzo Innocente
2012-05-09 06:29:40 UTC ---
Hi Honza,
I forgot to say that I tried both
-flto-partition=1to1
and
-flto-partition=none
with the same result
the point is that the symbols in question refers to a templated fu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
--- Comment #2 from vincenzo Innocente
2012-05-08 14:01:27 UTC ---
understood why it is related to the order of the input files.
Still that particular symbol shall not be hidden.
I've a library with 307 of those symbols, and lto hides only 7 of t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53282
Bug #: 53282
Summary: lto and visibility-inlines-hidden makes "wrongly"
hidden symbols and in a way that depends on the order
of the input compilation units
Classification: Unclass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #14 from vincenzo Innocente
2012-05-08 09:18:01 UTC ---
added your patch on top of
c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #11 from vincenzo Innocente
2012-05-07 13:05:18 UTC ---
Please post on this PR when a version of 4.8 exists that supports the feature
(I saw several patches proposed and even committed)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423
--- Comment #9 from vincenzo Innocente
2012-05-07 13:01:51 UTC ---
For what "we" are concerned it is obsolete.
1) things changed somehow between 4.6.0 and 4.6.1
2) is not there anymore in 4.7 and 4.8
in any case the original problem was most pro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
--- Comment #10 from vincenzo Innocente
2012-05-07 12:23:41 UTC ---
"unfortunately" -flto-partition=1to1 fixes the ICE for the library in question.
I do not have any other standing ICE at the moment.
btw
I've applied the patch in comment 9 on th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
--- Comment #5 from vincenzo Innocente
2012-05-04 14:12:39 UTC ---
confirmed solved.
for the records:
gcc version 4.7.1 20120504 (prerelease) [gcc-4_7-branch revision 187154] (GCC)
with lto
we are left now with just one ice (PR53195) on abo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
vincenzo Innocente changed:
What|Removed |Added
Attachment #27289|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
vincenzo Innocente changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53195
--- Comment #1 from vincenzo Innocente
2012-05-04 09:22:30 UTC ---
does not happen with latest version of
gcc version 4.7.1 20120504 (prerelease) (GCC)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
Bug #: 53214
Summary: [lto]: ICE: munmap_chunk(): invalid pointer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53186
--- Comment #4 from vincenzo Innocente
2012-05-03 06:46:01 UTC ---
Ciao Paolo,
grazie per il patch.
Io no so quale sia lo "standard" gcc, ma credo sarebbe meglio distribuire patch
che si applicano direttamente dalla directory principale e non
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53186
--- Comment #3 from vincenzo Innocente
2012-05-03 06:42:46 UTC ---
not bad…
hope it could be back ported to 4.7.1
c++ -std=gnu++11 -c opFinal.cpp; nm opFinal.o; otool -t -v -V -X opFinal.o |
c++filt
00b0 s EH_frame1
002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49488
--- Comment #6 from vincenzo Innocente
2012-05-02 08:00:07 UTC ---
it looks to me that it is not effective with operators (see PR53186)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53186
Bug #: 53186
Summary: [C++11] missing devirtualization for operators "final"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
--- Comment #13 from vincenzo Innocente
2012-04-16 13:53:30 UTC ---
I confirm that "revision 186494" fixed PR53007.
btw:
would it be possible to add the revision number to the oyuout of "c++ -v"?
the current "version id"
gcc version 4.8.0 201204
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53007
Bug #: 53007
Summary: [4.8 REGRESSION] ICE verify_ssa failed with -Ofast and
lto
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52975
--- Comment #5 from vincenzo Innocente
2012-04-16 11:19:26 UTC ---
indeed.
will it be back-ported to 4.7.1?
btw
I find very "elegant" the
movaps(%rdx,%rax), %xmm0
minps%xmm1, %xmm0
movaps%xmm0, (%rcx,%rax)
produced by -Of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
--- Comment #13 from vincenzo Innocente
2012-04-13 13:35:19 UTC ---
Richard, please, look at PR59275.
I think your testcase CAN produce not optimized code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52975
Bug #: 52975
Summary: Ofast produces not optimized code for vectorized
"converted if"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
--- Comment #11 from vincenzo Innocente
2012-04-13 13:03:48 UTC ---
I do not have a clear case in hand with evidence of "double" compare
I will have a closer look to "real life" code.
btw
I just noticed that your test case does not vectorize ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
--- Comment #6 from vincenzo Innocente
2012-04-13 11:59:59 UTC ---
patch applied to latest trunk.
success on both cases.
thanks.
v.
p.s. optimizing the if-conversion to produce a single comparison will be
appreciated as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
--- Comment #4 from vincenzo Innocente
2012-04-13 11:31:37 UTC ---
Ready to test the patch.
I've another code that produces the same ICE in stl_algo.h:3264
not easy to reproduce in a small example...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52969
Bug #: 52969
Summary: ICE in in get_expr_operands, at
tree-ssa-operands.c:1035 with
-ftree-loop-if-convert-stores
Classification: Unclassified
Product: gcc
Ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #26 from vincenzo Innocente
2011-11-30 09:13:08 UTC ---
using a minimal configuration like
./configure --prefix=/something --enable-languages=c,c++ --disable-multilib
--disable-bootstrap --enable-lto -enable-gold=yes -disable-libitm
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #25 from vincenzo Innocente
2011-11-29 15:24:02 UTC ---
Thanks Jakub for the new patch.
Using it I get this: any Idea how to fix/avoid?
home/data/newsoft/gcc-trunk/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/home/data/newsoft/gcc-trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #23 from vincenzo Innocente
2011-11-29 10:10:06 UTC ---
a working patch could be useful to check performance and quality of the
generated ASM w.r.t. manually crafted soutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
--- Comment #21 from vincenzo Innocente
2011-11-29 09:54:49 UTC ---
My understanding is that we cannot count to see a "min/max location pattern"
vectorization in 4.7, isn't it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50622
--- Comment #6 from vincenzo Innocente
2011-11-29 09:42:31 UTC ---
This ICE is still present with revision 181800.
It does block our tests and validation of 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
--- Comment #30 from vincenzo Innocente
2011-11-20 14:20:14 UTC ---
sorry Dominique not to have been clear, Jonathan answer is correct.
For what I'm concerned this specific PR can be closed.
vincenzo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
vincenzo Innocente changed:
What|Removed |Added
CC||vincenzo.innocente at cern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
--- Comment #15 from vincenzo Innocente
2011-11-10 09:35:53 UTC ---
this morning segfault in ld!
svn update
At revision 181250.
./configure --enable-languages=c,c++,fortran --disable-multilib
--disable-bootstrap --enable-lto
I get
Making all i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51062
Bug #: 51062
Summary: SLP vectorization of dot (inner) product
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
--- Comment #6 from vincenzo Innocente
2011-11-09 13:32:52 UTC ---
For what concern AVX:
I'm not sure what done elsewhere in gcc
I think that configure should check that the "as" supports avx independently of
the architecture one is building on o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
vincenzo Innocente changed:
What|Removed |Added
Target||i686-apple-darwin11
Ho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
Bug #: 51031
Summary: build error in libitm (how to disable trans-mem???)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688
--- Comment #12 from vincenzo Innocente
2011-11-08 08:49:22 UTC ---
much better!
for the test in comment 7 now I get
c++ -O0 -shared -fPIC -fvisibility=hidden -o bha.so testICF.cpp
nm bha.so | c++filt | grep " T "
0e5c T go()
000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688
--- Comment #8 from vincenzo Innocente
2011-11-07 09:38:08 UTC ---
Reduced test
actually it is enough to add
s::foo(v);
in the main after s::foo(a);
to get
0e34 t void s::foo(A)
0e3a T void s::foo >(s::vector)
0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688
--- Comment #7 from vincenzo Innocente
2011-11-07 09:23:30 UTC ---
The situation now is even more confused.
Most of the std algos have iterators as arguments. Visibility seems not to
propagate there..
below is my extensive test
compile as
c++ -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
--- Comment #11 from vincenzo Innocente
2011-10-31 16:16:54 UTC ---
the example in comment 10 compiles fine if I add a move constructor
D(A && ia) : a(ia) {}
or a "by value constructor"
D(A ia) : a(ia) {}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
--- Comment #10 from vincenzo Innocente
2011-10-31 16:06:41 UTC ---
using the patch of comment 8
in the example below I get
$ c++ -std=gnu++0x -c talias.cc
$ c++ -std=gnu++0x -c talias.cc -DALIAS
talias.cc: In instantiation of ‘Bar::D Bar::d()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #9 from vincenzo Innocente
2011-10-28 14:00:18 UTC ---
That's a pity.
It would be very useful though to have at least a patch to test so that we can
have something to use in prototypes and eventually a working solution for 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #7 from vincenzo Innocente
2011-10-28 09:06:30 UTC ---
sorry to ping again.
Stage 1 is supposed to end Nov 7th.
Will the new feature work out by Sri make for 4.7?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50849
vincenzo Innocente changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50849
Bug #: 50849
Summary: long long right shift not vectorized
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50819
--- Comment #3 from vincenzo Innocente
2011-10-22 14:50:01 UTC ---
excellent!
thanks Ira for the fast fix.
It does work. No side effect at first look
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50819
Bug #: 50819
Summary: missed SLP vectorization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818
--- Comment #7 from vincenzo Innocente
2011-10-20 07:27:30 UTC ---
no side effects for the time being.
I've tried only small applications though.
I would suggest to rename --disable-visibility
--disable-std-visibility or similar as, applied to to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50756
Bug #: 50756
Summary: request to better handle non-constant distance vectors
to avoid unnecessary alias check
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745
vincenzo Innocente changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745
--- Comment #7 from vincenzo Innocente
2011-10-16 15:32:29 UTC ---
At a first look --disable-visibility does the job..
have to check exception. the #pragma is still there though.
I think I can experiment with that.
thanks Paolo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745
--- Comment #2 from vincenzo Innocente
2011-10-16 14:20:19 UTC ---
I want just to remove _GLIBCXX_VISIBILITY(default) from namespace std so that
visibility of std::xyz can be inherited from the outer scope for instance when
compiling with -fvisib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #17 from vincenzo Innocente
2011-10-16 13:47:22 UTC ---
cool!
even
signed char k[1024];
61void foo6() {
62 for (int i=0; i!=N; ++i)
63k[i] = (a[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745
Bug #: 50745
Summary: proposal to make visibility of namespace gcc
configurable
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #6 from vincenzo Innocente
2011-10-15 13:40:31 UTC ---
I now moved to a more realistic case that can be reduced to this:
void loop(float * x, int n) {
for (int i=0;i!=n; ++i)
x[i]=x[i+n]+x[i+2*n];
}
and it creates aliases e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50713
--- Comment #3 from vincenzo Innocente
2011-10-14 12:54:46 UTC ---
thanks for the splitting: it is indeed the most serious problem.
what about "complex ops in scalar code"? keep it here and shall I spawn a
specific one (maybe once PR50622 is fixe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50713
Bug #: 50713
Summary: SLP vs loop: code generated differs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #3 from vincenzo Innocente
2011-10-12 17:00:40 UTC ---
the patch work for me.
Does not seem to break anything else.
thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
Bug #: 50698
Summary: pretending to create versioning for alias when not
required
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
301 - 400 of 493 matches
Mail list logo
