On Mon, Apr 19, 2010 at 5:54 PM, Jeff Law l...@redhat.com wrote:
combine requires a data dependency, so for this situation, combine isn't
going to help. The easy solution is to create a peephole. You can also
create a machine dependent reorg pass to detect more of these opportunities.
Hi, all
I have been working on implementing a tool-set of code assistance called
GCCSense, which enables code-completion for C/C++ in editors or a terminal.
http://cx4a.org/software/gccsense/
GCCSense depends on its own GCC which has special options for code
assistance such like
Tomohiro Matsuyama wrote:
Hi, all
I have been working on implementing a tool-set of code assistance called
GCCSense, which enables code-completion for C/C++ in editors or a terminal.
http://cx4a.org/software/gccsense/
GCCSense depends on its own GCC which has special options for code
Hi,
when putting together a patch to fix PR 43812 I wanted to extend
the call graph verifier to verify that
1) the same_comdat_group linked lists are indeed circular,
2) there are no one element lists, and
3) all nodes in such lists have the flag DECL_COMDAT (node-decl) set.
However, the third
On Wed, Apr 21, 2010 at 01:53:21PM +0200, Martin Jambor wrote:
when putting together a patch to fix PR 43812 I wanted to extend
the call graph verifier to verify that
1) the same_comdat_group linked lists are indeed circular,
2) there are no one element lists, and
3) all nodes in such lists
On Wed, Apr 21, 2010 at 01:12:37PM +0200, Basile Starynkevitch wrote:
However, I am not sure to understand why Tomohiro needs to hack the
GCC parser itself. I was thinking that he might instead write a
plugin which works at the Generic/TREE (or even perhaps Gimple)
level.
That doesn't make
On 21 April 2010 12:32, Tomohiro Matsuyama t...@cx4a.org wrote:
Hi, all
I have been working on implementing a tool-set of code assistance called
GCCSense, which enables code-completion for C/C++ in editors or a terminal.
http://cx4a.org/software/gccsense/
GCCSense depends on its own GCC
Frank Isamov frank.isa...@gmail.com writes:
1. Is it possible to add a machine dependent reorg pass at backend
level without changing the standard infrastructure? If so, can you
please point me such example? If no, may the new plugin architecture
help here?
See
On Wed, Apr 21, 2010 at 4:42 PM, Ian Lance Taylor i...@google.com wrote:
2. A peephole for such case just repeats instruction definition
pattern. As all information already available for such peephole,
wouldn’t it be useful to implement the pass to be a part of the
standard infrastructure?
On 04/21/10 00:39, Frank Isamov wrote:
On Mon, Apr 19, 2010 at 5:54 PM, Jeff Lawl...@redhat.com wrote:
combine requires a data dependency, so for this situation, combine isn't
going to help. The easy solution is to create a peephole.You can also
create a machine dependent reorg pass
Daniel Jacobowitz wrote:
On Wed, Apr 21, 2010 at 01:12:37PM +0200, Basile Starynkevitch wrote:
However, I am not sure to understand why Tomohiro needs to hack the
GCC parser itself. I was thinking that he might instead write a
plugin which works at the Generic/TREE (or even perhaps Gimple)
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've had about as much
luck getting the patch to fix this...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
Sorry if I haven't reviewed
On Tue, Apr 20, 2010 at 01:22:32AM -0700, Manuel López-Ibáñez wrote:
Is there any one against advertising GCC to the fullest extent? The
problem, as always, is who will do this job. But I don't think nobody
will be against if you create a GCC blog/tweeter/youtube channel and
start writing nice
Duncan Sands wrote:
Hi Steven,
I think Jack wasn't suggesting that dragonegg should be changed to
not be
a plugin any more. I think he was suggesting that it should live in
the gcc
repository rather than the LLVM repository.
So, no offense, but the suggestion here is to make this
Joe Buck wrote:
If someone wants to volunteer to write an article about all the delicious
goodness of 4.5.0, that would be cool, and lwn.net and others would
be interested in publishing such a thing. But the RMs have enough work
to do as is, so it shouldn't be up to Mark to produce a
Vladimir Makarov wrote:
Duncan Sands wrote:
Hi Steven,
I think Jack wasn't suggesting that dragonegg should be changed to
not be
a plugin any more. I think he was suggesting that it should live in
the gcc
repository rather than the LLVM repository.
So, no offense, but the suggestion here
On Wed, Apr 21, 2010 at 6:53 PM, Vladimir Makarov vmaka...@redhat.com wrote:
One interesting thing is that dragonegg is a really fast compiler. It
is 2.3 times faster than gcc.
Yes, well, this is one thing the crowd out there complains about all
the time. It just appears to be almost
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewar de...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on current
PC's, using just
On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've had about as much
luck getting the patch to fix this...
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:53 PM, Vladimir Makarov vmaka...@redhat.com wrote:
One interesting thing is that dragonegg is a really fast compiler. It
is 2.3 times faster than gcc.
Yes, well, this is one thing the crowd out there complains about all
the time. It
Well your review does pretty much amount to because darwin lacks
objdump like linux, the patch is rejected
Please reread.
Paolo
On 21 April 2010 18:49, Joe Buck joe.b...@synopsys.com wrote:
On Tue, Apr 20, 2010 at 01:22:32AM -0700, Manuel López-Ibáñez wrote:
Is there any one against advertising GCC to the fullest extent? The
problem, as always, is who will do this job. But I don't think nobody
will be against if you
Robert Dewar wrote:
Vladimir Makarov wrote:
Duncan Sands wrote:
Hi Steven,
I think Jack wasn't suggesting that dragonegg should be changed to
not be
a plugin any more. I think he was suggesting that it should live
in the gcc
repository rather than the LLVM repository.
So, no offense, but
On 21 April 2010 19:14, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
If someone wants to volunteer to write an article about all the delicious
goodness of 4.5.0, that would be cool, and lwn.net and others would
be interested in publishing such a thing. But the RMs have enough work
to do
On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've
On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:
Hi, all
I have been working on implementing a tool-set of code assistance called
GCCSense, which enables code-completion for C/C++ in editors or a terminal.
http://cx4a.org/software/gccsense/
This approach seems highly, uh,
On Wed, Apr 21, 2010 at 07:22:47PM +0200, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably
On Wed, Apr 21, 2010 at 07:10:21PM +0200, Paolo Bonzini wrote:
Well your review does pretty much amount to because darwin lacks
objdump like linux, the patch is rejected
Please reread.
Paolo,
You say...
The patch is not okay, it is if you use nm -g on Darwin only.
However in the
On Apr 21, 2010, at 9:53 AM, Vladimir Makarov wrote:
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
So here is SPECInt2000 for x86_64 comparison:
On 04/21/2010 06:35 PM, Chris Lattner wrote:
On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:
Hi, all
I have been working on implementing a tool-set of code assistance
called GCCSense, which enables code-completion for C/C++ in editors
or a terminal.
On 21 April 2010 19:11, Vladimir Makarov vmaka...@redhat.com wrote:
I don't think we should be too much worried about it. GCC looks good in
comparison with other industrial compiler with compile time point (and code
size too) of view (e.g. SunStudio compiler is about 2 times slower and
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewarde...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a
Hi Ian,
On Wed, Apr 21, 2010 at 5:42 PM, Ian Lance Taylor i...@google.com wrote:
Frank Isamov frank.isa...@gmail.com writes:
2. A peephole for such case just repeats instruction definition
pattern. As all information already available for such peephole,
wouldn’t it be useful to implement
Hi Vladimir, thank you for doing this benchmarking.
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
Sorry about that. Can you please send me preprocessed
On Wed, Apr 21, 2010 at 7:49 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Well your review does pretty much amount to because darwin lacks
objdump like linux, the patch is rejected
Stop that argument. You're fighting windmills.
I was referring to your repeated gcc-is-linux-centric
On Wed, Apr 21, 2010 at 07:48:36PM +0200, Paolo Bonzini wrote:
On 04/21/2010 07:42 PM, Jack Howarth wrote:
However in the past when I submitted patches for areas outside
of the darwin specific source files, they were rejected*if* they
made the code too darwin-centric.
Well, in this case I
On Wed, Apr 21, 2010 at 07:22:47PM +0200, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
On Wed, Apr 21, 2010 at 05:52:03PM +0200, Paolo Bonzini wrote:
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably
On 04/21/2010 07:42 PM, Jack Howarth wrote:
However in the past when I submitted patches for areas outside
of the darwin specific source files, they were rejected*if* they
made the code too darwin-centric.
Well, in this case I gave you a suggestion, so it was implicit that I'd
have approved
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewar de...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on
On 04/21/2010 07:51 PM, Jack Howarth wrote:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
/usr/lib64/libsqlite3.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
Chris Lattner wrote:
On Apr 21, 2010, at 9:53 AM, Vladimir Makarov wrote:
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
So here is SPECInt2000 for
Duncan Sands wrote:
Hi Vladimir, thank you for doing this benchmarking.
Only SPECIn2000 for x86_64 has been compiled fully successfully by
dragonegg. There were a few compiler crashes including some in LLVM
itself for SPECFP2000 and for SPECINT2000 for x86.
Sorry about that. Can you please
I am agree with this for moderately optimizing compilers. But for
highly optimizing compilers it might be no true. Intel generates much
better and bigger code than gcc. Although it might be mostly because of
code versioning (including one for different subtargets).
I don't think this is
On Apr 21, 2010, at 11:11 AM, Vladimir Makarov wrote:
This is definitely interesting, but you're also comparing apples and oranges
here (for both compile time and performance). Can you get numbers showing
GCC -O3 and dragonegg with LTO to get a better comparison?
Dragonegg does not
Paolo Bonzini wrote:
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewarde...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison
Manuel López-Ibáñez wrote:
On 21 April 2010 19:11, Vladimir Makarov vmaka...@redhat.com wrote:
I don't think we should be too much worried about it. GCC looks good in
comparison with other industrial compiler with compile time point (and code
size too) of view (e.g. SunStudio compiler is about
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewar de...@adacore.com wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on
From the early days, WATFOR was an impressively fast compiler,
and then there is always Borland Pascal.
I once gave a talk at the SIGPLAN compiler conference whose
theme was the great successes we were having in managing
to dramatically slow down compilers :-)
Chris Lattner wrote:
On Apr 21, 2010, at 11:11 AM, Vladimir Makarov wrote:
This is definitely interesting, but you're also comparing apples and oranges
here (for both compile time and performance). Can you get numbers showing GCC
-O3 and dragonegg with LTO to get a better comparison?
Hi,
I just compiled gcc-4.5.0 and accidentally found that
elfutils-libelf-0.145 (in at least Fedora 12) will work
in place of libelf version 0.8.12 (or later) that is
required per
http://gcc.gnu.org/install/prerequisites.html
I suggest adding sentences something like this to the
prerequisites
We (here we = the commercial company AdaCore) would be worried if
ANY of our customers were worried, but they are not, they see a
continuous effective improvement in compile speed using the latest
available hardware, and it's not a factor for them.
The Ada compiler is a little special here
Heyho!
I strongly suspect that mixing -flto and -g might not be a well supported
option right now ...
Still I also suspect an ICE is not supposed to happen. (I was trying to
recompile Debian's KDE packages with -flto; the packaging by default uses -g -
O2)
gcc Debian package 4.5.0-2 on amd64
On 3 April 2010 00:16, Jack Howarth wrote:
Jonathan,
The test program when compiled as i386 randomly hangs under both the
32-bit and 64-bit
kernels on Darwin 10.3.0. I've emailed Mike Stump an Instruments trace file
sampling the
hung binary. Unfortunately, I don't know how to convert
On 04/21/10 11:57, Frank Isamov wrote:
Instructions which manipulate with data in parallel and have no data
dependency automatically require peephole2 definition or/and machine
dependent reorg pass. (Please see an example at the bottom of this
email). Peephole2 pattern, in this case, just
Hi Vladimir,
Dragonegg does not work with -flto. It generates assembler code on which
gas complaints (a lot of non-assembler code like target data-layout
which are not in comments).
actually it does work with -flto, in an awkward way. When you use -flto
it spits out LLVM IR. You need to use
$ /usr/bin/g++-4.5 -O0 -g -flto -o kfinddialog.o -c kfinddialog.ii
../../kdeui/findreplace/kfinddialog.cpp: In member function ‘RegExpAction’:
../../kdeui/findreplace/kfinddialog.cpp:445:9: internal compiler error: tree
check: expected class ‘type’, have ‘declaration’ (function_decl) in
On Wed, Apr 21, 2010 at 9:03 PM, Adrian von Bidder avbid...@fortytwo.ch wrote:
Heyho!
I strongly suspect that mixing -flto and -g might not be a well supported
option right now ...
Still I also suspect an ICE is not supposed to happen. (I was trying to
recompile Debian's KDE packages with
On 21 April 2010 19:49, Andrew Haley a...@redhat.com wrote:
On 04/21/2010 06:35 PM, Chris Lattner wrote:
On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:
Hi, all
I have been working on implementing a tool-set of code assistance
called GCCSense, which enables code-completion for C/C++
Robert Dewar wrote:
I am agree with this for moderately optimizing compilers. But for
highly optimizing compilers it might be no true. Intel generates
much better and bigger code than gcc. Although it might be mostly
because of code versioning (including one for different subtargets).
On Wed, Apr 21, 2010 at 08:07:48PM +0100, Jonathan Wakely wrote:
On 3 April 2010 00:16, Jack Howarth wrote:
Jonathan,
The test program when compiled as i386 randomly hangs under both the
32-bit and 64-bit
kernels on Darwin 10.3.0. I've emailed Mike Stump an Instruments trace file
Robert Dewar wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on current
PC's, using just one core).
Obviously, apart from comparing a
On 21 April 2010 21:54, Jack Howarth wrote:
On Wed, Apr 21, 2010 at 08:07:48PM +0100, Jonathan Wakely wrote:
On 3 April 2010 00:16, Jack Howarth wrote:
Jonathan,
The test program when compiled as i386 randomly hangs under both the
32-bit and 64-bit
kernels on Darwin 10.3.0. I've
Paolo Bonzini bonz...@gnu.org writes:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
The equivalent of objdump -T is nm -D.
Andreas.
--
Andreas Schwab,
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab sch...@linux-m68k.org wrote:
Paolo Bonzini bonz...@gnu.org writes:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
The
On Wed, Apr 21, 2010 at 3:44 PM, Paolo Bonzini bonz...@gnu.org wrote:
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab sch...@linux-m68k.org wrote:
Paolo Bonzini bonz...@gnu.org writes:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm:
On Thu, Apr 22, 2010 at 12:44:42AM +0200, Paolo Bonzini wrote:
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab sch...@linux-m68k.org wrote:
Paolo Bonzini bonz...@gnu.org writes:
I'm not sure if nm -g would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm:
Paolo,
We don't have -D in our nm. How about the following change to
configure.ac?
Ok. See? ;-)
As a followup, if you have access to a Linux machine you can try
removing the objdump requirement altogether.
(Thanks Eric too).
Paolo
On Apr 21, 2010, at 1:51 PM, Manuel López-Ibáñez wrote:
http://cx4a.org/software/gccsense/
This approach seems highly, uh, inspired from the exact same
functionality in Clang. Any reason not to contribute to that
effort?
Surely trying to persuade people to contribute to some other
Summary for unix/-m64 ===
# of expected passes16
=== gcc Summary ===
# of expected passes32
/home/howarth/work/gcc/xgcc version 4.5.1 20100421 (prerelease) (GCC)
make[1]: Leaving directory `/home/howarth/work/gcc'
Jack
the compilation of PR16923.c now fails with...
Executing on host:
/sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.5.999-20100421/gcc-4.6-20100421/libjava/testsuite/libjava.jni/invocation/PR16923.c
Hello,
having finally built myself a 4.5.0 (linux x86-64), i've quickly tried
it on some of my code and it soon became apparent some things weren't
for the better.
Here's my febrile attempt to sum up what surprised me
$ cat huh.cc
#include cmath
#if __GNUC__ * 100 + __GNUC_MINOR__ 405
On 21/04/10 19.30, tbp wrote:
Hello,
having finally built myself a 4.5.0 (linux x86-64), i've quickly tried
it on some of my code and it soon became apparent some things weren't
for the better.
In any case, keep in mind that constexpr are not available yet, maybe
the parser can already
The dead store problem seems to be a regression in SRA. In 4.4, the
struct with array is properly expanded in to scalars allowing copy
prop and dead code elimination -- in 4.5, this does not happen. You
should file a bug .
David
On Wed, Apr 21, 2010 at 7:30 PM, tbp tbp...@gmail.com wrote:
This revised patch builds plugin support fine on x86_64-apple-darwin10 and
x86_64 Fedora 10...
Ok for trunk and 4.5 branch after a few days.
Paolo
--- Comment #25 from jason at gcc dot gnu dot org 2010-04-21 06:06 ---
Subject: Bug 9335
Author: jason
Date: Wed Apr 21 06:06:27 2010
New Revision: 158586
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158586
Log:
PR c++/9335
gcc/cp:
* init.c (constant_value_1):
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 06:56 ---
Works just fine here. Are you sure you have updated also to the latest
fortran/openmp.c and rebuilt f951?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43826
--- Comment #28 from mikpe at it dot uu dot se 2010-04-21 07:52 ---
(In reply to comment #27)
I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it
first
when my 4.5-based gcc regressed on this test, and found evidence that trunk
regressed similary between
--- Comment #29 from rguenther at suse dot de 2010-04-21 08:48 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
On Tue, 20 Apr 2010, mikpe at it dot uu dot se wrote:
--- Comment #27 from mikpe at it dot uu dot se
--- Comment #12 from redi at gcc dot gnu dot org 2010-04-21 09:23 ---
(In reply to comment #8)
By the way, there's no warning with -Wall or even -Wextra. Is there a flag
-Wabsolutely_all_warnings_we_promise that I have missed and that would really
enable *all* warnings ?
No, sorry,
It would be very nice if gcc emitted debug information that allowed profilers
and debuggers the option to extract a stack trace which included calls to
inlined functions. This would allow developers much greater insight into the
behavior of optimized code.
C++ programs would benefit
--- Comment #1 from scovich at gmail dot com 2010-04-21 09:29 ---
(In reply to comment #0)
One more way debugging would improve: it would become possible to set
breakpoints in inlined functions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-21 09:29 ---
They are feasible, but they do need a very strict specification to be usable.
With 4.6 you can check the -alias dumps when building with -flto -fipa-pta
to see if the compiler maybe can already analyze the situation
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org
|dot org
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-21 09:40 ---
Right, this is a GNU extension used to implement the library, which was later
standardised. We also support 'long long' in C++03 mode.
GCC is not intended to be a strict ANSI C++ verification tool, so doesn't
reject
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 10:01 ---
It works for me on x86_64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 10:03 ---
GCC already emits that (and emits that for quite some time already).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 10:31 ---
BTW, gcc stopped emitting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=129882
- PR10220 commit.
Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
could find any discussions about it
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:38
---
(In reply to comment #10)
Unfortunately that change isn't even mentioned in the ChangeLog entry nor I
could find any discussions about it on the mailing list from that time.
In the bugzilla PR you reference,
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-21 10:43 ---
Yeah, that's exactly the hunk I'm referring to. The gdb patch Jan provided
relies on DW_AT_MIPS_linkage_name (or DW_AT_linkage_name hopefully for DWARF4)
to be provided. While for most normal Fortran identifiers
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:46
---
I have googled the gcc.gnu.org domain for my name and DW_AT_MIPS_linkage_name,
and came up with nothing relevant. So, I never proposed or sought to get this
part approved, which confirms it's probably just human
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-04-21 10:47
---
There are two problems here:
1. The immediate problem is that movsi_m68k doesn't allow (const) to be moved
to data register (see last alternative if movsi_m68k).
2. For reason, which I have not yet investigated,
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR D.3163_8, D.3164_9;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to
--- Comment #9 from rguenther at suse dot de 2010-04-21 11:44 ---
Subject: Re: C complex numbers, amd64 SSE, missed
optimization opportunity
On Wed, 21 Apr 2010, irar at il dot ibm dot com wrote:
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes,
--- Comment #6 from oberlaender at fzi dot de 2010-04-21 11:48 ---
A test with a g++-4.4.2 I built myself has the same problem:
$ g++-4.4.2 -c -o bugtest.out -O2 bugtest.ii
projects/odete/bugtest.cpp: In member function bool
tBspTree2D::Intersect(const tVec2f, const tVec2f, tVec2f,
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-21 11:49 ---
(In reply to comment #4)
Subject: Re: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal
compiler error)
Can you bisect the few commits that happened inbetween? Like reverting
the fixes for PRs
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-21 11:58 ---
Subject: Bug 43570
Author: jakub
Date: Wed Apr 21 11:57:42 2010
New Revision: 158594
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158594
Log:
PR middle-end/43570
* omp-low.c
465.tonto in one of its hot loops does essentially what the following reduced
testcase does:
subroutine make_esss(esss,Ix,Iyz,e_x,ii_ivec)
real(kind=kind(1.0d0)), dimension(:), intent(inout) :: esss
real(kind=kind(1.0d0)), dimension(:,:), pointer :: Ix,Iyz
integer(kind=kind(1)),
--- Comment #12 from burnus at gcc dot gnu dot org 2010-04-21 12:25 ---
Close as FIXED. If someone feels strong about allowing -fcheck=recursion with
-fopenmp, please reopen. (I think as fopenmp implies -frecursive, it does not
make much sense.)
--
burnus at gcc dot gnu dot org
1 - 100 of 224 matches
Mail list logo
