2012年4月10日15:26 Eric Botcazou :
>> Something like -Wdefault-warnings is a reasonable choice, for the
>> reasons already mentioned in this sub-thread.
>
> Purists will find that -Wdefault-warnings is redundant though, since -W is
> supposed to mean "warning" already, e.g. it's -Wall and not -Wall-wa
On Tue, Apr 10, 2012 at 2:07 AM, Miles Bader wrote:
> 2012年4月10日15:26 Eric Botcazou :
>>> Something like -Wdefault-warnings is a reasonable choice, for the
>>> reasons already mentioned in this sub-thread.
>>
>> Purists will find that -Wdefault-warnings is redundant though, since -W is
>> supposed
>> GCC does warn if returning a pointer to a local variable (stack memory).
>> But there are alot of more cases where GCC could possibly warn,
>> eg. when references are made to local variables or stack memory.
>>
>> See this attached example code.
>> GCC warns for first case, but not the others.
On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> Class hierarchy is one such feature that is useful. Assuming we have
> two hierarchies for gcc: one for values rooted at ValExp, and one for
> gimple stmts rooted at GimpInst.
>
> 1) For IR browsing,
>*) all the macro accesso
> I will now start looking into the second problem,
>
> > 2) The 'X' lines in the ALI files are not what they should be.
> > This is due to the fact that Lib.Xref.Generate_(Definition|Reference)
> > is
> > called during semantic analysis. However, when I discover that a
> > tree was already built
On Mon, Apr 9, 2012 at 8:51 PM, Lawrence Crowl wrote:
> On 4/9/12, Jakub Jelinek wrote:
>> On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
>> > A build conversion to C++ is a precondition to any source change
>> > using C++, though the two could be bundled into one patch. In any
On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li wrote:
> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
> wrote:
>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt
>> wrote:
>>> On 04/04/2012 11:06 AM, Richard Guenther wrote:
So - I'll veto the switch unless I see 1) and 2). 1) and 2)
hey gcc everything will fall into place if you want it to
http://www.cnbc13online.com
hey gcc you really should get involved in this http://www.cnbc28web.com/finance/
hey gcc i have no more boundaries http://www.cnbc29news.com
Hi,
On Tue, 10 Apr 2012, Jakub Jelinek wrote:
> >*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
> >
> > e.g.
> > exp->as_component_ref().get_field() ..
> > exp->as_mem_access().get_base() ...
> > exp->as_mem_acesss().get_address()
On Mon, Apr 9, 2012 at 20:26, Gerald Pfeifer wrote:
> Done for i386-unknown-freebsd10.0 (GCC 4.2 as system compiler).
> No problems.
Thanks!
Diego.
On 10 April 2012 13:11, NightStrike wrote:
> Generally speaking, I've tried to help people get us a clean build of
> gcc warning-wise for the windows targets. This has historically been
> challenging mainly due to printf. Kai added a lot of support for
> handling whacky windows printfs, and we we
Hi,
On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
> > To be honest, all of those sound fine to me...
> >
> > bike-sheddin',
> > -miles
>
> at the risk of more bike sheds: -Wcommon ?
To use a variant of your own counterargument against -Wdefault: "common"
also has a special commonly (ahem :) u
Hi,
I have added two entries:
alpha64-dec-openvms - currently as failed. I still have to investigate the
support of weak symbols by the assembler
ia64-hp-openvms - pass. But it requires some patches for Ada.
Tristan.
On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo wrote:
> My plea for help is to everyone who has access to the targets
> mentioned in the list: please follow the instructions in that page and
> fill-in the table entries of the targets that you tested.
>
> If you see a missing target that should be t
On 4/10/12 8:41 AM, Tristan Gingold wrote:
Hi,
I have added two entries:
alpha64-dec-openvms - currently as failed. I still have to investigate the
support of weak symbols by the assembler
ia64-hp-openvms - pass. But it requires some patches for Ada.
Thanks. If the alpha64 failure is due t
On 4/10/12 9:04 AM, NightStrike wrote:
On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo wrote:
My plea for help is to everyone who has access to the targets
mentioned in the list: please follow the instructions in that page and
fill-in the table entries of the targets that you tested.
If you see
On Tue, Apr 10, 2012 at 8:38 AM, Jonathan Wakely wrote:
> On 10 April 2012 13:11, NightStrike wrote:
>> Generally speaking, I've tried to help people get us a clean build of
>> gcc warning-wise for the windows targets. This has historically been
>> challenging mainly due to printf. Kai added a l
On Tue, Apr 10, 2012 at 9:07 AM, Diego Novillo wrote:
> On 4/10/12 9:04 AM, NightStrike wrote:
>>
>> On Fri, Apr 6, 2012 at 6:55 PM, Diego Novillo wrote:
>>>
>>> My plea for help is to everyone who has access to the targets
>>> mentioned in the list: please follow the instructions in that page an
On 04/05/2012 03:21 PM, Gabriel Dos Reis wrote:
> On Thu, Apr 5, 2012 at 5:50 AM, Andrew Haley wrote:
>> On 04/04/2012 07:02 PM, Gabriel Dos Reis wrote:
Oh, wow. Really? That's a big change. Time to be brave, I guess,
> but I very much like the idea of a gcc that does just what it's to
On Apr 10, 2012, at 3:07 PM, Diego Novillo wrote:
> On 4/10/12 8:41 AM, Tristan Gingold wrote:
>> Hi,
>>
>> I have added two entries:
>> alpha64-dec-openvms - currently as failed. I still have to investigate the
>> support of weak symbols by the assembler
>> ia64-hp-openvms - pass. But it req
On 04/05/2012 12:30 PM, Vincent Lefevre wrote:
> On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
>> On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
>>> On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
> Really? Such as what?
Such
On 4/10/12 9:27 AM, NightStrike wrote:
Do these have to be tested as native compilers or cross compilers?
It doesn't really matter. As long as stage 1 is built with the host C++
compiler, either type of build should be fine.
Diego.
Andrew Haley writes:
> The argument is that we should enable the warnings by default because
> it makes gcc more competitive. But that only makes gcc more
> competitive if enabling these kinds of warnings by default is an
> advantage. However, we haven't established that -Wall by default is
> ad
On Tue, Apr 10, 2012 at 3:25 PM, NightStrike wrote:
> On Tue, Apr 10, 2012 at 8:38 AM, Jonathan Wakely
> wrote:
>> On 10 April 2012 13:11, NightStrike wrote:
>>> Generally speaking, I've tried to help people get us a clean build of
>>> gcc warning-wise for the windows targets. This has historic
Tested x86_64-apple-darwin10, pdp11-aout -- both pass.
paul
On Tue, Apr 10, 2012 at 9:56 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 3:25 PM, NightStrike wrote:
>> On Tue, Apr 10, 2012 at 8:38 AM, Jonathan Wakely
>> wrote:
>>> On 10 April 2012 13:11, NightStrike wrote:
Generally speaking, I've tried to help people get us a clean build of
On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sheds: -Wcommon ?
>
> To use a variant of your own counterargument
Diego Novillo writes:
> My plea for help is to everyone who has access to the targets
> mentioned in the list: please follow the instructions in that page and
> fill-in the table entries of the targets that you tested.
i386-pc-solaris2.10 just passed, although I had several special-case
options
On Tue, Apr 10, 2012 at 7:40 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
>
>> > To be honest, all of those sound fine to me...
>> >
>> > bike-sheddin',
>> > -miles
>>
>> at the risk of more bike sheds: -Wcommon ?
>
> To use a variant of your own counterargument
On Tue, Apr 10, 2012 at 4:00 PM, NightStrike wrote:
> On Tue, Apr 10, 2012 at 9:56 AM, Richard Guenther
> wrote:
>> On Tue, Apr 10, 2012 at 3:25 PM, NightStrike wrote:
>>> On Tue, Apr 10, 2012 at 8:38 AM, Jonathan Wakely
>>> wrote:
On 10 April 2012 13:11, NightStrike wrote:
> Generall
On 4/10/12 10:35 AM, Rainer Orth wrote:
sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
9 to 11) if desired.
That would be great, particularly if they use different host C++
compilers. Thanks.
If you see a missing target that should be tested, by all means, add
it
On 4/10/12 9:59 AM, paul_kon...@dell.com wrote:
Tested x86_64-apple-darwin10, pdp11-aout -- both pass.
Thanks.
Diego.
Diego Novillo writes:
> On 4/10/12 10:35 AM, Rainer Orth wrote:
>
>> sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
>> 9 to 11) if desired.
>
> That would be great, particularly if they use different host C++ compilers.
Currently, they all use versions of g++ 4.4, but I
Hi,
This patch for x86-64 psABI adds document for STT_GNU_IFUNC and
R_X86_64_IRELATIVE. It has been implemented on Linux/x86-64 for
more than a year. Please add it to x86-64 psABI.
Thanks.
--
H.J.
ifunc-spec.patch
Description: Binary data
On Tue, Apr 10, 2012 at 8:26 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Jakub Jelinek wrote:
>
>> > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>> >
>> > e.g.
>> > exp->as_component_ref().get_field() ..
>> > exp->as_mem_access().g
On Tue, 10 Apr 2012, Rainer Orth wrote:
Diego Novillo writes:
On 4/10/12 10:35 AM, Rainer Orth wrote:
sparc-sun-solaris2.11 in progress, could add other OS versions (Solaris
9 to 11) if desired.
That would be great, particularly if they use different host C++ compilers.
Currently, they
Marc Glisse writes:
>> Currently, they all use versions of g++ 4.4, but I could give it a try
>> with different versions of Sun/Oracle Studio CC.
>
> They should all fail, versions up to 12.2 because of CC bugs (reported to
> Oracle and fixed in 12.3 I think), and version 12.3 at least because of
On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn wrote:
> Also, it will be more convenient to make this change incrementally,
> but the GCC community probably will not see much benefit until the
> transition is complete. That also means developers asserting benefits
> need to be realistic and se
On Tue, Apr 10, 2012 at 5:26 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Jakub Jelinek wrote:
>
>> > *) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
>> >
>> > e.g.
>> > exp->as_component_ref().get_field() ..
>> > exp->as_mem_access().g
On 4/10/12 12:05 PM, Gabriel Dos Reis wrote:
On Tue, Apr 10, 2012 at 10:50 AM, David Edelsohn wrote:
Also, it will be more convenient to make this change incrementally,
but the GCC community probably will not see much benefit until the
transition is complete. That also means developers assert
On Tue, 10 Apr 2012, Rainer Orth wrote:
Marc Glisse writes:
Currently, they all use versions of g++ 4.4, but I could give it a try
with different versions of Sun/Oracle Studio CC.
They should all fail, versions up to 12.2 because of CC bugs (reported to
Oracle and fixed in 12.3 I think), an
Marc Glisse writes:
>> Thanks for the heads-up, that saved me time and effort. Do you have CRs
>> for the CC bugs?
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575
>
> I think that was it, but I can't remember for sure.
On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> Class hierarchy is one such feature that is useful. Assuming we have
>> two hierarchies for gcc: one for values rooted at ValExp, and one for
>> gimple stmts rooted at Gimp
Hi,
On Tue, 10 Apr 2012, Xinliang David Li wrote:
> >> > exp->as_component_ref().get_field() ..
> > Actually it's not questionable. The above stuff is _horrible_.
>
> Specifics please. It is _horrible_ because you are more used to the
> existing way and the new style does not mat
On Tue, 10 Apr 2012, Rainer Orth wrote:
Marc Glisse writes:
Thanks for the heads-up, that saved me time and effort. Do you have CRs
for the CC bugs?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073575
I think that was it, b
I am trying to resubscribe to the various GCC mailing lists with my new address
and the
web based subscribe doesn't seem to be working. Has anyone else noticed this
problem?
While at http://gcc.gnu.org/lists.html, I tried to subscribe my new address
(sell...@mips.com)
to the digest form of gcc
On Tue, Apr 10, 2012 at 4:14 AM, Richard Guenther
wrote:
> On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li wrote:
>> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
>> wrote:
>>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt
>>> wrote:
On 04/04/2012 11:06 AM, Richard Guenther wrote:
>
On 04/05/2012 01:28 PM, Michael Veksler wrote:
> As for specific warnings, I hate that the the code (a&&b || c&&d),
> which did not cause a warning on older gcc version now gives a
> warning. I would not want it on by default since it forces users to
> write too many parentheses in ((a&&b)||(c&&d)
On 4/10/12 12:28 PM, Marc Glisse wrote:
On Tue, 10 Apr 2012, Rainer Orth wrote:
Marc Glisse writes:
Thanks for the heads-up, that saved me time and effort. Do you have CRs
for the CC bugs?
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073578
http://bugs.sun.com/bugdatabase/view_bug.d
On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek wrote:
> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> >> Class hierarchy is one such feature that is useful. Assuming we have
> >> two hierarchies for gcc:
On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> > Class hierarchy is one such feature that is useful. Assuming we have
> > two hierarchies for gcc: one for values rooted at ValExp, and one for
> > gimple stmts rooted a
On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek wrote:
>> What is the root cause of the annoyance? Mixing macros and inline
>> functions does not sound good, but using deeply nested macros do not
>> seem to help the debugging situation either.
>
> That when stepping through code in the debugger yo
On 4/10/12 12:42 PM, Gabriel Dos Reis wrote:
On Tue, Apr 10, 2012 at 11:39 AM, Jakub Jelinek wrote:
What is the root cause of the annoyance? Mixing macros and inline
functions does not sound good, but using deeply nested macros do not
seem to help the debugging situation either.
That when ste
On Tue, Apr 10, 2012 at 9:24 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
>> >> > exp->as_component_ref().get_field() ..
>
>> > Actually it's not questionable. The above stuff is _horrible_.
>>
>> Specifics please. It is _horrible_ because you are
On Tue, 2012-04-10 at 18:24 +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
> > >> > exp->as_component_ref().get_field() ..
>
> > > Actually it's not questionable. The above stuff is _horrible_.
> >
> > Specifics please. It is _horrible_ becaus
On Tue, 2012-04-10 at 18:39 +0200, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
> > > Not to mention it is very questionable if the above stuff is more readable
> > > than what we currently have.
> >
> > The above is just quickly cooked up examples. A c
Michael Matz writes:
> syntactic noise without any whitespace. Quite frankly, how anyone could
> ever say that
>
> exp->as_component_ref().get_field()
>
> is easier to read/write/use than
>
> GET_FIELD_DECL (exp)
C vs C++ is not the same argument as style A vs style B. Your argument
could
On Tue, Apr 10, 2012 at 9:39 AM, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 09:22:56AM -0700, Xinliang David Li wrote:
>> On Tue, Apr 10, 2012 at 1:46 AM, Jakub Jelinek wrote:
>> > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>> >> Class hierarchy is one such feature tha
> Think about programmers new to GCC for a second, and about code
> completion tools. It seems to me that with such a tool it's much easier
> to navigate from exp to the field, than having to scan through a much
> larger number of accessor functions / macros (GET_*). The former
> example starts a
Tests pass for xtensa-unknown-elf on 64-bit linux with host gcc 4.6.3.
Dave Weatherford
we...@tensilica.com
On 10/04/2012 17:24, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
> exp->as_component_ref().get_field() ..
>
>>> Actually it's not questionable. The above stuff is _horrible_.
>> Specifics please. It is _horrible_ because you are more used to th
On 10/04/2012 17:41, Paweł Sikora wrote:
> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>>> Class hierarchy is one such feature that is useful. Assuming we have
>>> two hierarchies for gcc: one for values rooted at
On Tue, 2012-04-10 at 19:59 +0200, Eric Botcazou wrote:
> > Think about programmers new to GCC for a second, and about code
> > completion tools. It seems to me that with such a tool it's much easier
> > to navigate from exp to the field, than having to scan through a much
> > larger number of acc
2012/4/10 Dave Korn :
> On 10/04/2012 17:41, Paweł Sikora wrote:
>> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
Class hierarchy is one such feature that is useful. Assuming we have
two hierarchies for gcc
It is my pleasure to announce the MELT plugin 0.9.5 release candidate 3 for GCC
4.6 or
4.7.
The release candidate 3 of MELT plugin 0.9.5 is still perhaps buggy but is
available from
http://gcc-melt.org/melt-0.9.5rc3-plugin-for-gcc-4.6-or-4.7.tar.gz as a gzipped
tar
archive of 4476348 bytes an
> Or are you really saying that the number of characters determines how
> quickly/easily a brain can remember/find something like an API
> item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are
> the most likely (sub-)parts of function names shouldn't it be G_F_D
> (exp) then? ;)
On Tue, 2012-04-10 at 23:12 +0200, Eric Botcazou wrote:
> > Or are you really saying that the number of characters determines how
> > quickly/easily a brain can remember/find something like an API
> > item/keyword/...? If so, and if we assume that GET, FIELD, and DECL are
> > the most likely (sub-
Torvald Riegel writes:
> I hate to bring this up, but in my personal experience, getting started
> with LLVM was _much_ easier than with GCC. LLVM is a much newer
> codebase, so that's an advantage unrelated to the language.
I dunno, I've some experience with LLVM as well, and I actually found
i
2012/4/5 Diego Novillo
> I will be, after the switch to C++ is done. Pedro, if you do have a
> copyright assignment, feel free to start working on this. I suggest
> creating a branch for this (I can handle that today). If you need
> forms for the copyright assignment, let me know and I'll forw
On 04/10/2012 11:39 PM, Miles Bader wrote:
> Torvald Riegel writes:
>> I hate to bring this up, but in my personal experience, getting started
>> with LLVM was _much_ easier than with GCC. LLVM is a much newer
>> codebase, so that's an advantage unrelated to the language.
>
> I dunno, I've some
On 4/10/12 6:04 PM, Pedro Lamarão wrote:
2012/4/5 Diego Novillo
I will be, after the switch to C++ is done. Pedro, if you do have a
copyright assignment, feel free to start working on this. I suggest
creating a branch for this (I can handle that today). If you need
forms for the copyright as
> I can't derive a definition of "token" from your example that seems
> meaningful. It can't be parser tokens I assume, because you split
> GET_FIELD_DECL (but why in 2 not 3?).
FIELD_DECL is a single object, see tree.def.
> Following another comment in the thread, what are the concepts you'd
>
> In the short term, a partial conversion to C++ gains us nothing. Even
> ignoring the bugs inevitably caused by any such project, we'll end up
> with a strange mish-mash of styles for a very long time, which instead
> of helping anyone can only lead to confusion. I don't see anyone
> committing to
On Tue, Apr 10, 2012 at 6:27 PM, Eric Botcazou wrote:
>> In the short term, a partial conversion to C++ gains us nothing. Even
>> ignoring the bugs inevitably caused by any such project, we'll end up
>> with a strange mish-mash of styles for a very long time, which instead
>> of helping anyone can
On 4/10/12, Jakub Jelinek wrote:
> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
> > Class hierarchy is one such feature that is useful. Assuming we
> > have two hierarchies for gcc: one for values rooted at ValExp,
> > and one for gimple stmts rooted at GimpInst.
> >
> > 1) F
On 4/10/12, Richard Guenther wrote:
> On Apr 9, 2012 Lawrence Crowl wrote:
> > On 4/9/12, Jakub Jelinek wrote:
> > > On Mon, Apr 09, 2012 at 10:55:46AM -0700, Lawrence Crowl wrote:
> > > > A build conversion to C++ is a precondition to any source
> > > > change using C++, though the two could be
On 4/10/12, Jakub Jelinek wrote:
> That when stepping through code in the debugger you keep
> enterring/exiting these one liner inlines, most of them really
> should be at least by default considered just as normal statements
> (e.g. glibc heavily uses artificial attribute for those, still
> gdb d
On Mon, Apr 9, 2012 at 7:02 PM, Richard Guenther
wrote:
> On Mon, Apr 9, 2012 at 8:00 AM, Bin.Cheng wrote:
>> On Fri, Mar 30, 2012 at 5:43 PM, Bin.Cheng wrote:
>>
>> Hi Richard,
>> I am testing a patch to sink load of memory to proper basic block.
>> Everything goes fine except auto-vectorizati
On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
> The standard says they need not ignore them.
>
> I was thinking more about iterating over the contents. What in the
> current code is an indirect function call inside of a loop becomes
> mostly be inline functions in a C++ iterator
81 matches
Mail list logo
