On 2024-09-03 20:43:54 +0200, Simon Josefsson via gnu-prog-discuss wrote:
> I think a regexp like this should cover it all:
>
> (Mass Ave|Massachusetts Ave|Temple Pl|Franklin St|Milk St)
>
> It covers 'Temple Pl' that I couldn't find any occurances for, and 'Milk
> St' for future problems.
The '
On 2012-05-01 18:17:12 -0600, Eric Blake wrote:
> On 05/01/2012 06:11 PM, Vincent Lefevre wrote:
> > If (either the standard one or from Gnulib) is used
> > together with GCC's
> >
> > __attribute__ ((noreturn))
> >
> > in the other package, thing
On 2012-04-29 18:28:03 +0200, Bruno Haible wrote:
> And clashes regarding the 'noreturn' macro? I don't see any. In a compilation
> unit, the last definition matters, and since both definitions (from gnulib
> and from the other package) are supposedly correct, what is the problem?
If (either the
On 2012-04-29 09:56:03 -0700, Paul Eggert wrote:
> On 04/29/2012 08:34 AM, Vincent Lefevre wrote:
> >I don't like the fact that you assume by default that compilers
> >are non-conforming
>
> Nor do I. How about the following improvement to the heuristic?
> It is just
On 2012-04-29 16:19:35 +0200, Bruno Haible wrote:
> Vincent Lefevre wrote:
> > modules/snippet/_Noreturn references build-aux/snippet/_Noreturn.h,
> > which is:
> >
> > #ifndef _Noreturn
> > # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GN
On 2012-04-29 16:11:38 +0200, Bruno Haible wrote:
> Paul Eggert wrote:
> > it might make sense to try to do it in a more Autoconfish way.
>
> The reason why we do this with explicit #ifs that test for a compiler
> brand, not in an "Autoconfish way", is that we use the result in .h
> files that sho
On 2012-04-26 09:27:08 -0700, Russ Allbery wrote:
> I've done the experiment from time to time of supporting -ansi or
> --std=c99, but even for small code bases I consider it the kind of thing
> that one does as a hobby or out of curiosity. It's not a very good way to
> actually get work done and
On 2012-04-26 12:08:50 -0400, Nick Bowler wrote:
> On 2012-04-26 17:56 +0200, Vincent Lefevre wrote:
> > But I think that is not a solution for MPFR, due to
> > the potential clashes with GMP (on which we depend), which uses GCC's
> > __attribute__ ((noreturn)). Thoug
On 2012-04-26 09:15:53 -0600, Eric Blake wrote:
> On 04/26/2012 09:02 AM, Vincent Lefevre wrote:
> > On 2012-04-26 08:14:51 -0600, Eric Blake wrote:
> >> If I write C11 code:
> >>
> >> #include
> >> #include
> >>
> >> then I e
On 2012-04-26 08:14:51 -0600, Eric Blake wrote:
> If I write C11 code:
>
> #include
> #include
>
> then I expect things to work. But _MSC_VER system headers use noreturn
> in a non-C11 manner, such that the only way for this to work via gnulib
> is to make 'noreturn' a no-op on that platform,
On 2012-04-25 10:24:19 -0600, Eric Blake wrote:
> Right now, gnulib already has not only such a macro, but also a
> replacement header that supports this functionality for
> generic C11 compilers and older GCC, as well as working around a bug in
> MSVC vs. native Windows headers and their use of '
On 2011-09-07 13:22:09 +0200, Simon Josefsson wrote:
> Vincent, Bruno, if you can think of ways of making the situation better
> even for projects that use libtool wrappers of self-tests, then let's do
> that too -- I'm just mentioning that -no-install may be a solution.
Yes, I think this should b
Hi,
I've just done a test with the GNU MPC trunk, which is now based
on valgrind-tests.m4, and this is not compatible with libtool,
because it generates wrapper scripts.
valgrind-tests.texi says:
However, this means that binaries invoked through scripts will not be
invoked under valgrind, which
different packages.
>
> Ad 1)
> Vincent Lefevre wrote:
> > > You are better off filing this report against gettext, which is the
> > > source of this file, and/or gnulib, which ships the latest version
> > > of this file even in packages (such as m4) that have not
Hi,
On 2008-11-14 21:11:56 -0700, Eric Blake wrote:
> You are better off filing this report against gettext, which is the
> source of this file, and/or gnulib, which ships the latest version
> of this file even in packages (such as m4) that have not yet
> undergone the I18n conversion to use gette
On 2006-12-31 11:37:21 -0500, Richard Kenner wrote:
> Certainly. Indeed I think that's the whole point of this thread: that if
> you want to catch ALL potential optimizations opportunities given to you
> by the standard, you must assume that signed overflows are undefined.
>
> However, what's bei
On 2006-12-31 11:01:45 -0500, Robert Dewar wrote:
> The issues are
>
> a) are these optimizations valuable? (and if so, in all cases,
>or only in practice for loop invariants?).
Even if they aren't valuable today, you don't know what will happen
in future code. So, there's another issue: is i
On 2006-12-31 10:19:59 -0500, Richard Kenner wrote:
> > If done in unsigned, this won't lead to any optimization, as unsigned
> > arithmetic doesn't have overflows. So, if you write "a - 10" where a
> > is unsigned, the compiler can't assume anything, whereas is a is
> > signed, the compiler can as
On 2006-12-31 10:08:32 -0500, Richard Kenner wrote:
> > Well, that's not equivalent. For instance, MPFR has many conditions
> > that evaluate to TRUE or FALSE on some/many implementations (mainly
> > because the type sizes depend on the implementation), even without
> > the assumption that an overf
On 2006-12-31 10:07:44 -0500, Robert Dewar wrote:
> Vincent Lefevre wrote:
> >If done in unsigned, this won't lead to any optimization, as unsigned
> >arithmetic doesn't have overflows. So, if you write "a - 10" where a
> >is unsigned, the compiler can
On 2006-12-31 09:22:22 -0500, Robert Dewar wrote:
> Vincent Lefevre wrote:
> >>My point was that if you see this in a source program, it is in
> >>fact a possible candidiate for code that can be destroyed by
> >>the optimization.
> >
> >Well, only for non-
On 2006-12-31 09:08:21 -0500, Richard Kenner wrote:
> > In fact the wrap around range test is a standard idiom for "hand
> > optimization" of range tests.
>
> It's also one that GCC uses internally, but you do it in *unsigned*
> to avoid the undefined overflow.
If done in unsigned, this won't lea
On 2006-12-31 09:03:17 -0500, Richard Kenner wrote:
> > And I doubt that GCC (or any compiler) could reliably detect code
> > that checks for overflow.
>
> It doesn't need to "detect" all such code: all it needs to do is
> ensure that it doesn't BREAK such code. And that's a far easier
> condition
On 2006-12-31 08:06:56 -0500, Robert Dewar wrote:
> Vincent Lefevre wrote:
> >On 2006-12-30 20:07:09 -0500, Robert Dewar wrote:
> >> In my view, this comparison optimization should not have been put in
> >> without justification given that it clearly does affect the
On 2006-12-31 08:25:23 -0500, Richard Kenner wrote:
> > > > I suppose there is
> > > >
> > > > *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1;
> > > >
> > > > to make it safe.
> > >
> > > Can't that conversion overflow?
> >
> > Not on a two's complement machine,
>
> Then I'm confuse
On 2006-12-30 19:29:58 -0500, Robert Dewar wrote:
> Richard Kenner wrote:
> >I can't speak for any other GCC developer, but I personally am
> >quite comfortable viewing any code that assumes wrapping semantics
> >as broken and needing fixing with the exception of these cases of
> >checking for over
On 2006-12-30 20:07:09 -0500, Robert Dewar wrote:
> In my view, this comparison optimization should not have been put in
> without justification given that it clearly does affect the semantics
> of real code. Indeed if you really see code like
>
>if (a - 10 < 20)
>
> in place of
>
>i
27 matches
Mail list logo
