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 -code-comple
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
assist
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
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 mak
On 21 April 2010 12:32, 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 ha
Frank Isamov 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 TARGET_MACHINE_DEPENDENT_REORG.
> 2. A peep
On Wed, Apr 21, 2010 at 4:42 PM, Ian Lance Taylor 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?
>
> See
On 04/21/10 00:39, Frank Isamov wrote:
On Mon, Apr 19, 2010 at 5:54 PM, Jeff Law 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
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)
leve
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 a
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 n
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 subversiv
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 beau
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 i
On Wed, Apr 21, 2010 at 6:53 PM, Vladimir Makarov 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 impossible for GCC (the
p
On Wed, Apr 21, 2010 at 6:56 PM, 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).
Heh,
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...
>>
>> http://gcc
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:53 PM, Vladimir Makarov 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 a
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 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 create a GCC blog
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 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
On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth 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 had about as muc
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, "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
> 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
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
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.
>>
>> http://cx4a.o
On 21 April 2010 19:11, Vladimir Makarov 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
> generates worse code o
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, 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
Hi Ian,
On Wed, Apr 21, 2010 at 5:42 PM, Ian Lance Taylor wrote:
> Frank Isamov 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 the pass to be a part of the
>
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 c
On Wed, Apr 21, 2010 at 7:49 PM, Jack Howarth 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" accusation.
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
On Wed, Apr 21, 2010 at 07:22:47PM +0200, Steven Bosscher wrote:
> On Wed, Apr 21, 2010 at 7:09 PM, Jack Howarth
> 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
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 t
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, 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 jus
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 x86
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 se
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?
>>
>>
> Dragone
Paolo Bonzini wrote:
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, 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 lin
Manuel López-Ibáñez wrote:
On 21 April 2010 19:11, Vladimir Makarov 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
Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, 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 jus
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 p
> 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 con
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 repeat
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
gen_type_d
On Wed, Apr 21, 2010 at 9:03 PM, Adrian von Bidder 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 -flto; the pac
On 21 April 2010 19:49, Andrew Haley 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/
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).
I
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 tra
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 sufficie
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 Darwi
Paolo Bonzini 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, sch...@linux-m
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
> Paolo Bonzini 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 "obj
On Wed, Apr 21, 2010 at 3:44 PM, Paolo Bonzini wrote:
> On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
>> Paolo Bonzini 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
>>>
>>> $ objdu
On Thu, Apr 22, 2010 at 12:44:42AM +0200, Paolo Bonzini wrote:
> On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
> > Paolo Bonzini 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
>
> 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
howarth/gcc/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
=== gcc 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
cxxflags -shared-libgcc -lgcj -liconv
+lappend cxxflags "-shared-libgcc -lgcj $libiconv"
}
if { [istarget "*-*-solaris*"] } {
However the compilation of PR16923.c now fails with...
Executing on host:
/sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/gcc/xgcc
-
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
#if __GNUC__ * 100 + __GNUC_MINOR__ < 405
#define
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 reco
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 wrote:
> Hello,
>
> having fin
> 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
Vladimir Makarov wrote:
Although it is not right argument to what you mean. But example about
vectorization would be right. ICC vectorizes many more loops than gcc
does. Vectorized loops is much bigger in size than their non-vectorized
variants. So faster code does not mean smaller code in
Toon Moene wrote:
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 c
On Thu, Apr 22, 2010 at 6:36 AM, Paolo Carlini wrote:
> In any case, keep in mind that constexpr are not available yet, maybe the
> parser can already recognize some uses but the semantics is not done yet.
Ah, so it was nothing but smokes & mirrors. Thanks for the clarification.
On Thu, Apr 22, 2010 at 7:23 AM, Xinliang David Li wrote:
> The dead store problem seems to be a regression in SRA.
Thanks for looking into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
On Wed, 21 Apr 2010 14:40:51 -0400
Donald Parsons wrote:
> The package elfutils-libelf-0.145 (or later) also
> supplies the libelf prerequisite. Version 0.142 does
> not work. (versions 0.143, 0.144 unknown)
anything >=0.143 will work.
--
fonts,
79 matches
Mail list logo
