Re: Article suggestion (note for admin)

We have many STDs. stdio stdlib libstdc++ On Tue, Nov 7, 2023 at 7:57 AM Dwayne Jacobs < d.jac...@backgroundchecksmailing.org> wrote: > Hi GCC Team, > > I wanted to follow up once more regarding the latest STD statistics in the > US. > > As I mentioned previously, I believe the data could be a u

Article suggestion (note for admin)

Hi GCC Team, I wanted to follow up once more regarding the latest STD statistics in the US. As I mentioned previously, I believe the data could be a useful resource for your audience. You can find the full report here: https://backgroundchecks.org/which-states-have-the-most-stds.html If you'r

Re: A suggestion for going forward from the RMS/FSF debate

> > > Of computer science graduates I have encountered over the last decade, I > > know few who started their journey with gcc and they were all in the > > initial part of the decade. In recent years I don't think I encountered > > any student who works on gcc; many even start with the assumption

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Monday, April 19, 2021 at 4:58 AM > From: "Thomas Rodgers" > To: "Christopher Dimech" > Cc: "Siddhesh Poyarekar" , "GCC Development" > , "Ville Voutilainen" > Subject: Re: A suggestion for going forward from th

Re: A suggestion for going forward from the RMS/FSF debate

On 2021-04-18 00:38, Christopher Dimech via Gcc wrote: Listen very carefully - In the first quarter of 2011, Keith Chuvala began discussing the need to drop all proprietary systems used to command the ISS. He specifically mentioned products from Microsoft and Red Hat. This was communicated to

Re: A suggestion for going forward from the RMS/FSF debate

On 2021-04-17 20:10, Christopher Dimech via Gcc wrote: You have specified that the community does not require my approval or that of Eric Raymond. That is true of course. But many have gone through so much new age training that they ended up with a very sophisticated way of bullshitting them

Re: A suggestion for going forward from the RMS/FSF debate

Some had contacted me about it. Could have sent response off the list. > Sent: Monday, April 19, 2021 at 1:05 AM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going

Re: A suggestion for going forward from the RMS/FSF debate

with hindsight... > Sent: Sunday, April 18, 2021 at 11:06 PM > From: "Ville Voutilainen" > To: "Richard Kenner" > Cc: "Christopher Dimech" , "GCC Development" > , siddh...@gotplt.org > Subject: Re: A suggestion for going forward from the

Re: A suggestion for going forward from the RMS/FSF debate

> It is an argument against the idea that LLVM is the default way that > people choose. I don't think that anybody made the argument that LLVM is the "default" in any sense. What's being given here are reasons why some people prefer LLVM over GCC. > In those places, they don't trust Microsoft o

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 10:49 PM > From: "Richard Kenner" > To: dim...@gmx.com > Cc: gcc@gcc.gnu.org, siddh...@gotplt.org, ville.voutilai...@gmail.com > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > Depends on the use ca

Re: A suggestion for going forward from the RMS/FSF debate

On Sun, 18 Apr 2021 at 13:49, Richard Kenner wrote: > > > Depends on the use cases. Not in military surveillance. And certainly not > > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > > I'm not sure. Before 2011, rather than building things from scratch, > > washi

Re: A suggestion for going forward from the RMS/FSF debate

> Depends on the use cases. Not in military surveillance. And certainly not > at Lawrence Livermore National Laboratory. At Boeing could be the same, but > I'm not sure. Before 2011, rather than building things from scratch, > washington bureaucrats simply picked from among existing technology.

Re: A suggestion for going forward from the RMS/FSF debate

> You will not get funding grants in the US if you mention free software, > because the US Department of Commerce does not allow it. This is not correct and I suspect is a misunderstanding of what "government data rights" means.

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/F

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 9:06 PM > From: "Jonathan Wakely via Gcc" > To: "Aaron Gyes" > Cc: "gcc@gcc.gnu.org" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sun, 18 Apr 2021, 10:01 Christopher Dimech vi

Re: A suggestion for going forward from the RMS/FSF debate

On Sun, 18 Apr 2021, 10:01 Christopher Dimech via Gcc, wrote: > You don't have to believe me of course. Go ask any lawyer worth her > salt and she'll tell you the same thing! > And if they don't tell you the same thing, they're obviously not a true Scotsman.

Re: A suggestion for going forward from the RMS/FSF debate

You don't have to believe me of course. Go ask any lawyer worth her salt and she'll tell you the same thing! > Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Aaron Gyes" > To: "Christopher Dimech" > Cc: gcc@gcc.gnu.org > Subject: Re: A suggest

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 7:53 PM > From: "Siddhesh Poyarekar" > To: "Christopher Dimech" > Cc: "NightStrike" , "Ville Voutilainen" > , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/F

Re: A suggestion for going forward from the RMS/FSF debate

- Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Sunday, April 18, 2021 at 7:46 PM > From: "Siddhesh Poyarekar" > To: "Gabriel Ravier" , gcc@gcc.gnu.org > Subject: Re: A suggestion for going forward fro

Re: A suggestion for going forward from the RMS/FSF debate

On 4/18/21 1:08 PM, Christopher Dimech wrote: The cause IMO is accessibility to other projects, most notably compiler researchers and students who find it a lot easier to target llvm than gcc because compiler-as-a-library. License may have been a factor for some of those uses (e.g. I know some w

Re: A suggestion for going forward from the RMS/FSF debate

ng ownership claims. Also Red Hat, > but I consider it minimal. Apple has a very long history of aggressive > legal actions. > >> Sent: Sunday, April 18, 2021 at 7:24 PM >> From: "Aaron Gyes" >> To: "Christopher Dimech" >> Subject: Re: A su

Re: A suggestion for going forward from the RMS/FSF debate

> Correct. The Apache License included certain patent termination and > counterclaim provisions, made void and null by the LLVM Exceptions. > Originally, the LLVM License > was based on the two free software licenses - the X11 license and the > 3-clause BSD license. By 2005, Apple managed to

Re: A suggestion for going forward from the RMS/FSF debate

On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote: I'd like to see a source for that. It certainly seems like complete bullshit to me, unless you're trying to tell me that they simultaneously do not fund anything related to free software while also having policy that mandates at least 20 percent

Re: A suggestion for going forward from the RMS/FSF debate

On 4/18/21 8:44 AM, Christopher Dimech via Gcc wrote: Sent: Sunday, April 18, 2021 at 6:09 PM From: "Siddhesh Poyarekar" To: "NightStrike" , "Ville Voutilainen" Cc: "GCC Development" Subject: Re: A suggestion for going forward from the RMS/FSF debate

Re: A suggestion for going forward from the RMS/FSF debate

ent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21 12:11 AM, NightStr

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 6:09 PM > From: "Siddhesh Poyarekar" > To: "NightStrike" , "Ville Voutilainen" > > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On 4/17/21

Re: A suggestion for going forward from the RMS/FSF debate

On 4/17/21 12:11 AM, NightStrike via Gcc wrote: I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. Intel, IBM, nVi

Re: A suggestion for going forward from the RMS/FSF debate

> Furthermore, it continues to nullify the Apache License by allowing patent > treachery. The LLVM License is thus a perfidious license intended to > allow the licensor to sue you at their choosing.= “Patent treachery”? And the intent of the license is to... accommodate lawsuits? That’s some ver

A suggestion for going forward from the RMS/FSF debate

I was under the (likely incorrect, please enlighten me) impression that the meteoric rise of LLVM had more to do with the license allowing corporate contributors to ship derived works in binary form without sharing proprietary code. - NightStrike You are correct. LLVM is under the Apache License

A suggestion for going forward from the RMS/FSF debate

You have specified that the community does not require my approval or that of Eric Raymond. That is true of course. But many have gone through so much new age training that they ended up with a very sophisticated way of bullshitting themselves. Regards Christopher > I'll see my work in GCC11 th

Re: A suggestion for going forward from the RMS/FSF debate

On 2021-04-17 12:08, Christopher Dimech wrote: Thomas, So we are decided? I am not pushing anybody down the cliff - rms, you or anybody. I simply wish that after a few world wars, people start seeing the light and things will be somewhat blissed out working on free software. In a lot of w

Re: A suggestion for going forward from the RMS/FSF debate

On 2021-04-17 10:40, Ville Voutilainen via Gcc wrote: On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: I do not see people really intending to fork. It explains why detractors have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ ma

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 5:40 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "Jason Merrill" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Sat, 17 Apr 2021

Re: A suggestion for going forward from the RMS/FSF debate

On Sat, 17 Apr 2021 at 20:31, Christopher Dimech wrote: > I do not see people really intending to fork. It explains why detractors > have gone berserk. I appreciate your colorful exaggerations, but I should point out that the libstdc++ maintainer has stated his intention to fork, in unambigous t

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Sunday, April 18, 2021 at 5:07 AM > From: "Ville Voutilainen" > To: "Jason Merrill" > Cc: "Christopher Dimech" , "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021

Re: A suggestion for going forward from the RMS/FSF debate

quot; > > > Cc: "GCC Development" > > > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > > > > > On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > > > > The "small minority of developers" you s

Re: A suggestion for going forward from the RMS/FSF debate

> >> It would be usefull to clarify with the FSF and GNU what the > >> actual relations are, > > Why? What would that gain? I go back to my analogy of the British Queen. > > What would be gained by "clarifying" that if she actually intervenes > > non-trivially in the government of any Commonwealt

Re: A suggestion for going forward from the RMS/FSF debate

Le 16/04/2021 à 19:06, Richard Kenner a écrit : >> The authority of the FSF, GNU and RMS over GCC is and has been a >> fiction for decades, > For the most part, I agree. > >> It would be usefull to clarify with the FSF and GNU what the >> actual relations are, > Why? What would that gain? I go ba

Re: A suggestion for going forward from the RMS/FSF debate

> On Apr 16, 2021, at 2:41 PM, NightStrike via Gcc wrote: > >> ... > > I was under the (likely incorrect, please enlighten me) impression > that the meteoric rise of LLVM had more to do with the license > allowing corporate contributors to ship derived works in binary form > without sharing p

Re: A suggestion for going forward from the RMS/FSF debate

On Fri, Apr 16, 2021 at 7:23 AM Ville Voutilainen via Gcc wrote: > On the first part, other people have touched on it already, > but the fear of a dreaded non-free software vendor co-opting > GCC as a library to a non-free project has resulted in GCC > being unsuitable to be used as a library in f

Re: A suggestion for going forward from the RMS/FSF debate

On 4/16/2021 9:57 AM, Thomas Koenig via Gcc wrote: Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. I don't think your emails have done any harm.  I find them quit

Re: A suggestion for going forward from the RMS/FSF debate

> The authority of the FSF, GNU and RMS over GCC is and has been a > fiction for decades, For the most part, I agree. > It would be usefull to clarify with the FSF and GNU what the > actual relations are, Why? What would that gain? I go back to my analogy of the British Queen. What would be ga

Re: A suggestion for going forward from the RMS/FSF debate

    From reading most of this thread, it is clear to me that     - The authority of the FSF, GNU and RMS over GCC is and has been a fiction for decades,     - This fiction has been erased from the official web page of the project,     - It would be usefull to clarify with the FSF and GNU what th

Re: A suggestion for going forward from the RMS/FSF debate

On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc wrote: > > Sent: Saturday, April 17, 2021 at 1:03 AM > > From: "Ville Voutilainen" > > To: "Christopher Dimech" > > Cc: "GCC Development" > > Subject: Re: A suggestion for

Re: A suggestion for going forward from the RMS/FSF debate

Hello world, realising that my e-mails may have done more harm than good, I will now unsubscribe from the gcc mailing list, so please don't expect a reply unless you copy me in. Best regards Thomas

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dim

Re: A suggestion for going forward from the RMS/FSF debate

On Fri, 16 Apr 2021 at 16:22, Christopher Dimech wrote: > Many do not contribute because they do not have time, resources or support. Yes? And? Even if GCC detaches itself from FSF, those who can contribute will continue to contribute. And those who talk about contributing but don't contribute wi

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Saturday, April 17, 2021 at 1:03 AM > From: "Ville Voutilainen" > To: "Christopher Dimech" > Cc: "GCC Development" > Subject: Re: A suggestion for going forward from the RMS/FSF debate > > On Fri, 16 Apr 2021 at 15:46, Christopher Dim

Re: A suggestion for going forward from the RMS/FSF debate

> Due to their being paid for the work. Have no doubt that if others > were being paid, the contributions could likely drown the current > contributors. Thus, the claim of a power grab is valid. This is a non-sequitur.

Re: A suggestion for going forward from the RMS/FSF debate

On Fri, 16 Apr 2021 at 15:46, Christopher Dimech wrote: > > The "small minority of developers" you speak of sure > > seems to consist of developers who are not in the minority > > considering how much they _actually contribute_ to the project. > > Due to their being paid for the work. Have no dou

Re: A suggestion for going forward from the RMS/FSF debate

> Sent: Friday, April 16, 2021 at 10:16 PM > From: "Ville Voutilainen via Gcc" > To: "GCC Development" > Subject: A suggestion for going forward from the RMS/FSF debate > > Huge apologies for mis-sending this to gcc-patches, > my email client makes sugg

A suggestion for going forward from the RMS/FSF debate

Huge apologies for mis-sending this to gcc-patches, my email client makes suggestions when I attempt to send to a gcc list. :D The actual suggestion is at the end; skip straight to it if you wish. >Im glad there are people like you on the project Eric, because you express exactly what a lot

Re: suggestion: c compiler warning for failure to test result

On Thu, 2017-04-27 at 10:42 -0600, Jeff Law wrote: > On 04/25/2017 05:02 PM, Martin Sebor wrote: > > On 04/25/2017 02:35 PM, Joe Perches wrote: > > > A possibly useful addition similar to: > > > > > > __attribute__((warn_unused_result)) > > > > > > might be > > > > > > __attribute__((warn_untest

Re: suggestion: c compiler warning for failure to test result

On 04/25/2017 05:02 PM, Martin Sebor wrote: On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree tha

Re: suggestion: c compiler warning for failure to test result

On 04/25/2017 02:35 PM, Joe Perches wrote: A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. I agree that this would be a useful feature. In fact, I

suggestion: c compiler warning for failure to test result

A possibly useful addition similar to: __attribute__((warn_unused_result)) might be __attribute__((warn_untested_result)) for things like allocation failures that are not verified before use. For instance: void *malloc(size_t size); could become void * __attribute((warn_untested_res

Re: Need suggestion about bug 68425

On 3 April 2016 at 16:56, Prasad Ghangal wrote: > > Also for > > int array[10]; > array[100]=10; > > Currently, GCC doesn't emit any warning (even with -Wall option) > > Wouldn't it be nice if GCC gives some warning like Clang, which gives: > > foo.c:4:3: warning: array index 100 is past the end o

Re: Need suggestion about bug 68425

On 5 March 2016 at 01:06, David Malcolm wrote: > On Wed, 2016-02-24 at 17:56 +0530, Prasad Ghangal wrote: >> Thanks Prathamesh and Joseph for your suggestions. >> >> Here is my updated patch : >> >> for test cases: >> >> const int array[5] = {1, 2, 3}; >> const int array1[3] = {1, 2, 3, 6}

Re: Need suggestion about bug 68425

On 4 March 2016 at 19:36, David Malcolm wrote: > Those caret locations look wrong to me - they don't seem to be > underlining the pertinent source. Is that what the patched compiler is > printing, or did things get messed up somewhere via email? Probably Gmail sucks at sending plain text. It suc

Re: Need suggestion about bug 68425

On Wed, 2016-02-24 at 17:56 +0530, Prasad Ghangal wrote: > Thanks Prathamesh and Joseph for your suggestions. > > Here is my updated patch : > > for test cases: > > const int array[5] = {1, 2, 3}; > const int array1[3] = {1, 2, 3, 6}; > const int array2[4] = {1, 2, 3, 6, 89}; > c

Re: Need suggestion about bug 68425

PING I would like to know if there is other better way of doing this. On 24 February 2016 at 17:56, Prasad Ghangal wrote: > Thanks Prathamesh and Joseph for your suggestions. > > Here is my updated patch : > > for test cases: > > const int array[5] = {1, 2, 3}; > const int array1[3] = {1

Re: Need suggestion about bug 68425

Thanks Prathamesh and Joseph for your suggestions. Here is my updated patch : for test cases: const int array[5] = {1, 2, 3}; const int array1[3] = {1, 2, 3, 6}; const int array2[4] = {1, 2, 3, 6, 89}; const int array3[5] = {1, 2, 3, 6, 89, 193}; const int array4[3] = {1, 2,

Re: Need suggestion about bug 68425

On Sun, 21 Feb 2016, Prasad Ghangal wrote: > - pedwarn_init (loc, 0, > -"excess elements in array initializer"); > + pedwarn_init (loc, 0, "excess elements in array initializer " > + "(%lu elements, expected %lu)", > + tree_to_uhwi (const

Re: Need suggestion about bug 68425

On 21 February 2016 at 12:32, Prasad Ghangal wrote: > I was working on PR68425, > > my untested patch : > > > diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c > --- a/trunk/gcc/c/c-typeck.c(revision 232768) > +++ b/trunk/gcc/c/c-typeck.c(working copy) > @@ -5856,7 +5856,7 @@ >

Re: Need suggestion about bug 68425

I was working on PR68425, my untested patch : diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c --- a/trunk/gcc/c/c-typeck.c(revision 232768) +++ b/trunk/gcc/c/c-typeck.c(working copy) @@ -5856,7 +5856,7 @@ component name is taken from the spelling stack. */ static void

Re: Need suggestion about bug 68425

On 19 February 2016 at 19:13, David Malcolm wrote: >> 68425.c:3:34: warning: excess elements in array initializer (6 >> elements, >> expected 2) >>const int array[2] = { 1, 2, 3 ,6 ,89 ,193}; >> ^ > > Yes, that would be ideal. Unfortunately,

Re: Need suggestion about bug 68425

to do. (in particular, INTEGER_CST doesn't. I hope to look into that for gcc 7, perhaps with a wrapper node to provide locations for expr nodes that don't have them). > But even without ranges, your suggestion would be a great > improvement. Agreed.

Re: Need suggestion about bug 68425

,193}; ^ Yes! Perhaps even (now that we have ranges!): 68425.c:3:34: warning: excess elements in array initializer (6 elements, expected 2) const int array[2] = { 1, 2, 3 ,6 ,89 ,193}; ^ But even without ranges, your suggestion would

Need suggestion about bug 68425

I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68425 For testcase const int array[2] = { 1, 2, 3 ,6 ,89 ,193}; gcc 6.0.0 produces warnings like (spacing may get disturbed by gmail) : 68425.c: In function ‘main’: 68425.c:3:34: warning: excess elements in array initializer

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/13/2013 01:02 PM, Chung-Ju Wu wrote: > 2013/9/13 Chen Gang : >> > On 09/13/2013 01:09 AM, Jeff Law wrote: >>> >> On 09/11/2013 10:38 PM, Chen Gang wrote: >>> Hello all: >>> > [...] >>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >>> bugs may dupl

Re: [Suggestion] about h8/300 architecture in gcc and binutils

2013/9/13 Chen Gang : > On 09/13/2013 01:09 AM, Jeff Law wrote: >> On 09/11/2013 10:38 PM, Chen Gang wrote: >>> Hello all: >>> [...] >>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >>> bugs may duplicate with these bugs, so I do not send (if they are also >>> valuable, I

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/13/2013 01:09 AM, Jeff Law wrote: > On 09/11/2013 10:38 PM, Chen Gang wrote: >> Hello all: >> >> I have send the related issues to "http://gcc.gnu.org/bugzilla";, please >> check if you like, thanks. >> >> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other >> bugs may dupl

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/11/2013 10:38 PM, Chen Gang wrote: > Hello all: > > I have send the related issues to "http://gcc.gnu.org/bugzilla";, please > check if you like, thanks. > > currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other > bugs may duplicate with these bugs, so I do not send (if the

Re: [Suggestion] about h8/300 architecture in gcc and binutils

Hello all: I have send the related issues to "http://gcc.gnu.org/bugzilla";, please check if you like, thanks. currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other bugs may duplicate with these bugs, so I do not send (if they are also valuable, I will send too). Next, I should

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/11/2013 03:55 AM, Michael Schewe wrote: > Hello Maintainers, > > if you like to drop h8/300 support in linux kernel, thats OK for me. OK, thanks. > But i like to see it still supported in gcc & binutils, at least i have > some projects and know companies using this architecture in embedded

Re: [Suggestion] about h8/300 architecture in gcc and binutils

Hello Maintainers, if you like to drop h8/300 support in linux kernel, thats OK for me. But i like to see it still supported in gcc & binutils, at least i have some projects and know companies using this architecture in embedded applications, bare metal without OS. These products have lifetime i

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/10/2013 10:19 AM, Jeff Law wrote: > On 09/09/2013 07:13 PM, Chen Gang wrote: >> Hello Maintainers: >> >> After google search and check the Linux kernel, H8/300 is dead, and for >> gcc-4.9.0 and binutils-2.23.2 still has h8300, do we still need it for >> another OS ? >> >> Welcome any suggesti

Re: [Suggestion] about h8/300 architecture in gcc and binutils

On 09/09/2013 07:13 PM, Chen Gang wrote: Hello Maintainers: After google search and check the Linux kernel, H8/300 is dead, and for gcc-4.9.0 and binutils-2.23.2 still has h8300, do we still need it for another OS ? Welcome any suggestions or completions, thanks. The related information in li

[Suggestion] about h8/300 architecture in gcc and binutils

Hello Maintainers: After google search and check the Linux kernel, H8/300 is dead, and for gcc-4.9.0 and binutils-2.23.2 still has h8300, do we still need it for another OS ? Welcome any suggestions or completions, thanks. The related information in linux kernel next tree: commit d02babe847b

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

[Apologies for reviving a long-dead thread, but in case it piques the interest of someone who has better knowledge of gcc internals...] Elmar Krieger writes: > For example, I got a huge slowdown also with this compiler: > > gcc44 (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) > Copyright (C) 2010 Free

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 8/13/12, Elmar Krieger wrote: > Good news, and especially the -ftime-report trick was highly useful. > > For example, I got a huge slowdown also with this compiler: > > gcc44 (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) > Copyright (C) 2010 Free Software Foundation, Inc. > > which spends all its time

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

> > [...] I really didn't expect that RedHat and Google both mess up > > GCC with their modifications, so I'll report it to them instead > > That's not a fair characterization of the features' costs/benefits. We just are trying to mess up (?) binutils, aren't we? gcc just receives the benefit b

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Elmar Krieger writes: > [...] I really didn't expect that RedHat and Google both mess up > GCC with their modifications, so I'll report it to them instead ;-) That's not a fair characterization of the features' costs/benefits. - FChE

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi Richard, many thanks for saving my time. time gcc -m32 -g -O -fno-strict-aliasing -x c -Wall -Werror -c model.i That's within reasonable bounds as well, IMHO (you can't really compare -O1 from 3.2.3 with -O1 from 4.6.3). One more data point (-O2 tends to be more focused on, no debuginfo g

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Fri, Aug 10, 2012 at 5:44 PM, Elmar Krieger wrote: > Hi Ian, hi Richard, hi Andi! > > Many thanks for your comments. > > The slowdown is not the same with other files, so I'm essentially sure that this specific source file has some 'feature' that catches GCC at the wrong leg. Thi

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/10/2012 10:44 AM, Elmar Krieger wrote: Hi Ian, hi Richard, hi Andi! Many thanks for your comments. >>> The slowdown is not the same with other files, so I'm essentially sure >>> that this specific source file has some 'feature' that catches GCC at >>> the wrong leg. This raises m

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 10 August 2012 16:53, Andrew Haley wrote: > On 08/10/2012 04:44 PM, Elmar Krieger wrote: >> I downloaded the latest official GCC 4.7.1, but unfortunately configure >> stopped with "Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC >> 0.8.0+.", and for my CentOS Linux, only older versions of th

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/10/2012 04:44 PM, Elmar Krieger wrote: > I downloaded the latest official GCC 4.7.1, but unfortunately configure > stopped with "Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC > 0.8.0+.", and for my CentOS Linux, only older versions of this libs are > available as RPMs. Go into the t

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi Ian, hi Richard, hi Andi! Many thanks for your comments. >>> The slowdown is not the same with other files, so I'm essentially sure >>> that this specific source file has some 'feature' that catches GCC at >>> the wrong leg. This raises my hopes that one of the GCC experts wants >>> to take a

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Thu, Aug 9, 2012 at 1:09 AM, Andi Kleen wrote: > Elmar Krieger writes: >> >> The slowdown is not the same with other files, so I'm essentially sure >> that this specific source file has some 'feature' that catches GCC at >> the wrong leg. This raises my hopes that one of the GCC experts wants

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Elmar Krieger writes: > > The slowdown is not the same with other files, so I'm essentially sure > that this specific source file has some 'feature' that catches GCC at > the wrong leg. This raises my hopes that one of the GCC experts wants > to take a look at it. The code is confidential, You co

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Wed, Aug 8, 2012 at 12:09 PM, Elmar Krieger wrote: >> Not at all high. See Type-Based Alias Analysis >> >> for one reason. > > Thanks, I read the article, but didn't really see how forbidding a function > with argument void** to

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi David, hi Andrew, One other thing I just thought of: GCC has a history of very smart extensions to C that allow to write faster and more elegant code. If I look at my code, there are mostly two sources of 'dirty hacks' left. One that could be fixed easily is the 'void** pointer problem', that

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/08/2012 03:01 PM, Elmar Krieger wrote: > To me, that just looks like a remnant from the ancient past that hinders > the future. On the other hand, my feeling tells me that this patch would > not be accepted, that's why I'm asking for my chances in advance ;-) Not at all high. See Type-Bas

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On 08/08/12 16:01, Elmar Krieger wrote: One other thing I just thought of: GCC has a history of very smart extensions to C that allow to write faster and more elegant code. If I look at my code, there are mostly two sources of 'dirty hacks' left. One that could be fixed easily is the 'void** poi

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Wed, Aug 8, 2012 at 4:01 PM, Elmar Krieger wrote: > Dear all, > > while I fully understand that GCC's steadily advancing optimization > capabilities can't be 'for free', the latest versions have become almost > unusably slow for me: > > With simple optimization -O, compiling a certain C source

New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Dear all, while I fully understand that GCC's steadily advancing optimization capabilities can't be 'for free', the latest versions have become almost unusably slow for me: With simple optimization -O, compiling a certain C source file (~6 lines) now takes 4.5 minutes, while older GCCs d

c preprocessor feature suggestion

i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an "evaluation" feature. s

Re: suggestion to use lzma for snapshots, maybe more?

On Wed, 13 Jan 2010, Vincent Lefevre wrote: >> I was idly looking through a couple of snapshots of the gcc -trunk line. >> I am by no means a compiler developer, but I did notice that you aren't >> using lzma for compression. I don't know if bandwidth is at all a >> concern, but I can point to a >

Re: suggestion for ppl and cloog-ppl configure enhancement

On Wed, Jan 13, 2010 at 14:55, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > IMHO it would be a godd idea to add the following two configure options to ppl > configure: >  --with-gmp-include=DIR  GMP include directory >  --with-gmp-lib=DIR      GMP lib directory > > On

  1   2   3   >