http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134
--- Comment #4 from joseph at codesourcery dot com 2012-04-27 10:23:42 UTC ---
On Fri, 27 Apr 2012, bugdal at aerifal dot cx wrote:
> Since even with the precision mode set correctly the exponent range of 387 fpu
> registers still matche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134
--- Comment #5 from joseph at codesourcery dot com 2012-04-27 10:26:22 UTC ---
See also what I said in
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html>:
The option naming leaves open the possibility of other options s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #3 from joseph at codesourcery dot com ---
We take the view that the preprocessor is deliberately meant to be limited
and overly complicated features in it would be contrary to the spirit of
C. Of course if they are introduced in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #7 from joseph at codesourcery dot com ---
On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote:
> That has not always stopped you all in the past, but that is really neither
We have plenty of experience dealing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #8 from joseph at codesourcery dot com ---
(And for recursion, even specification at the level of standard text might
leave something to be desired; I'd think specification at the level of
X3J11/86-196, the algorithm GCC tri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #10 from joseph at codesourcery dot com ---
On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote:
> (Stop the 'we'! Name or enumerate the group involved please.)
Well-established consensus among the GCC maintaine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #8 from joseph at codesourcery dot com ---
Thanks for working on this bug. http://gcc.gnu.org/contribute.html
describes how to submit changes (including testcases etc.).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:
> I think I understand consensus, but I only hear your voice here, not the voice
> of a multitude. You may be part of the con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58918
--- Comment #2 from joseph at codesourcery dot com ---
XALLOCA is a libiberty macro, target libraries shouldn't be using
libiberty headers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:
> Thank you, I will look info all of that. My own resources have limits; when
> it
> comes to testing generated cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 1 Nov 2013, michael at talamasca dot ocis.net wrote:
> Do I have to file a separate bug report in order to fix the problem that
> current GCC releases can't be expected t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 4 Nov 2013, mingjie.xing at gmail dot com wrote:
> 2013-11-04 Mingjie Xing
>
> * common.opt (Wa, Wl, Wp,): Change JoinedOrMissing to Joined.
That sounds wron
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #16 from joseph at codesourcery dot com ---
On Mon, 4 Nov 2013, mtewoodbury at gmail dot com wrote:
> Could you all give me some idea on how soon this might be applied?
At some time after seeing this on gcc-patches, I or anot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59035
--- Comment #2 from joseph at codesourcery dot com ---
If -ffp-contract=off is set for any object (whether explicitly, or
implicitly by an option such as -std=c99), the safe option for LTO would
be to set -ffp-contract=off at link time as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49661
--- Comment #3 from joseph at codesourcery dot com ---
libiberty is a C library. I don't consider that relevant to any code not
actually part of libiberty.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #22 from joseph at codesourcery dot com ---
On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote:
> There are also very strong grounds for not wanting IEEE 754 support by
> default, anyway, because of the performance impact and bec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #1 from joseph at codesourcery dot com ---
On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:
> propagation, or replace x*-y with -x*y, or move operations across fesetround,
Do you mean -(x*y)? I don't see the prob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #5 from joseph at codesourcery dot com ---
On Mon, 18 Nov 2013, rguenth at gcc dot gnu.org wrote:
> I wonder whether a very early pass splitting functions at FENV clobber
> points and preventing re-inlining would be a better so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 19 Nov 2013, mtewoodbury at gmail dot com wrote:
> it's been a couple weeks. Any progress?
I don't recall seeing this on gcc-patches (any patch attached to Bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
--- Comment #1 from joseph at codesourcery dot com ---
I see nothing at http://gcc.gnu.org/codingconventions.html that would
apply such a C++ coding practice to the mostly C-like code in GCC.
Changes to coding conventions should be proposed on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900
--- Comment #13 from joseph at codesourcery dot com ---
Isn't this the issue fixed by
2012-06-29 Andreas Schwab
* copying-lib.texi (Library Copying): Don't use @heading inside
@enumerate.
(which I more recently bac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #2 from joseph at codesourcery dot com ---
For powerpc see: http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html - the
failures indicate the architecture maintainers have not yet added this
hook.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #2 from joseph at codesourcery dot com ---
See: http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html - the failures
indicate the architecture maintainers have not yet added this hook (for
either SPARC, or ARM, or any non-x86 architecture).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #4 from joseph at codesourcery dot com ---
Feel free to add a comment mentioning the hook targets need to define for
this test to pass.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #8 from joseph at codesourcery dot com ---
It fails everywhere that (a) supports floating-point exceptions, (b) has
not had the target hook added and (c) supports pthreads ((c) is a
requirement for the test to run - the feature in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #22 from joseph at codesourcery dot com ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:
> The elaborate description of the different forms of the '#line' (and other)
> directives makes it clear that exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #24 from joseph at codesourcery dot com ---
On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:
> > The question is not when it takes place, it's what the "current token" is
> > when it takes plac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #11 from joseph at codesourcery dot com ---
On Mon, 2 Dec 2013, ebotcazou at gcc dot gnu.org wrote:
> Ugh. Linux and Solaris disagree on the values of the FE_* macros so we will
> need to have OS-dependent code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #12 from joseph at codesourcery dot com ---
One possibility would be to change libatomic/fenv.c to include a local
atomic-fenv.h (for example) header instead of (which would no
longer need a configure check), so that if the generic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #15 from joseph at codesourcery dot com ---
On Tue, 3 Dec 2013, ebotcazou at gcc dot gnu.org wrote:
> > In any case, c11-atomic-exec-5.c does not test anything relating to enabled
> > traps, although the feholdexcept c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943
--- Comment #4 from joseph at codesourcery dot com ---
I think it should be fixed for all C standard versions, not just C11 (that
is, the front end should produce something like (save (rhs), save (lhs) =
save (lhs) op save (rhs)) to get the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943
--- Comment #6 from joseph at codesourcery dot com ---
Yes, something like that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
--- Comment #1 from joseph at codesourcery dot com ---
This is a documentation bug - the installation manual should make clear
that "DWARF 2" in the description of this option means DWARF 2 or later,
as appropriate for the target, as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #3 from joseph at codesourcery dot com ---
The code generated appears fully in accordance with the semantics of C11.
You refer to 5.1.2.4#14, the definition of "carries a dependency". The
term "carries a depe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #5 from joseph at codesourcery dot com ---
On Thu, 12 Dec 2013, algrant at acm dot org wrote:
> demonstrates the same lack of ordering. You suggest that this might
> be a problem with the atomic built-ins - and yes, if this ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
--- Comment #12 from joseph at codesourcery dot com ---
On Sat, 14 Dec 2013, jan.kratochvil at redhat dot com wrote:
> Similar inappropriate warning is generated for typedef-vs-variable as reported
> now by Adam Jackson. Again a mistak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #1 from joseph at codesourcery dot com ---
The main concerns for diagnostics in such cases are (a) that they are
meaningful and (b) that invalid code gets at least one error with
-pedantic-errors, and at least one warning or error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
--- Comment #6 from joseph at codesourcery dot com ---
Indeed, I think the current token could reasonably be anything from
"assert" to the ")" ending the call to "assert", inclusive.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 16 Dec 2013, ktietz at gcc dot gnu.org wrote:
> The macros required in crtstuff.c are:
> - HAVE_GAS_HIDDEN
> - HAVE_LD_EH_FRAME_HDR
Various target macros used in target cod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 18 Dec 2013, manu at gcc dot gnu.org wrote:
> > The main concerns for diagnostics in such cases are (a) that they are
> > meaningful and (b) that invalid code gets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59520
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 20 Dec 2013, su at cs dot ucdavis.edu wrote:
> In particular, are the following well-defined according the standard or they
> have undefined behavior?
In both cases, y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146
--- Comment #6 from joseph at codesourcery dot com 2011-11-15 22:28:38 UTC ---
I think this is really a duplicate of an issue discussed in various places
before: libstdc++ relies on C library symbols that are not necessarily
reserved by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51181
--- Comment #2 from joseph at codesourcery dot com 2011-11-17 21:06:54 UTC ---
FWIW, classic m68k has compare-and-swap, while ColdFire Linux uses kernel
helpers (available in both vDSO and syscall forms; the syscall forms are
probably rather
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
--- Comment #26 from joseph at codesourcery dot com 2011-11-25 17:15:31 UTC ---
All the various options equivalent to -std=c99 now map to -std=c99 using
Alias in the .opt file, so specs only need to handle that one spelling.
The same applies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
--- Comment #1 from joseph at codesourcery dot com 2011-11-26 23:11:11 UTC ---
Note that this usage is not valid in C1X.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
--- Comment #3 from joseph at codesourcery dot com 2011-11-27 15:58:15 UTC ---
On Sun, 27 Nov 2011, tsoae at mail dot ru wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51316
>
> --- Comment #2 from Nikolka 2011-11-27 08:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #5 from joseph at codesourcery dot com 2011-12-02 16:09:57 UTC ---
On Fri, 2 Dec 2011, rguenth at gcc dot gnu.org wrote:
> Still the behavior of warning for -Wno- changed appearantly. Joseph?
The idea was that if an unknown -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766
--- Comment #6 from joseph at codesourcery dot com 2011-12-06 16:35:02 UTC ---
On Tue, 6 Dec 2011, rguenth at gcc dot gnu.org wrote:
> > The combination -fwrapv -ftrapv is not particularly meaningful; it ought
> > to act exactly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766
--- Comment #8 from joseph at codesourcery dot com 2011-12-06 20:12:12 UTC ---
On Tue, 6 Dec 2011, iant at google dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766
>
> --- Comment #7 from iant at google dot com
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51441
--- Comment #3 from joseph at codesourcery dot com 2011-12-06 20:17:36 UTC ---
Please identify the target for which the compiler is configured. If
32-bit x86, then note that in accordance with FLT_EVAL_METHOD you have
double rounding (two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #10 from joseph at codesourcery dot com 2011-12-07 20:56:01 UTC ---
On Wed, 7 Dec 2011, tromey at gcc dot gnu.org wrote:
> Note that GCC also handles the tab case incorrectly here.
Yes, GCC should be fixed to follow the GCS there
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #12 from joseph at codesourcery dot com 2011-12-08 20:37:11 UTC ---
I think the soft-fp code tries to generate particular target-specific NaNs
because it's also used in the Linux kernel emulation of floating-point
instruc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #14 from joseph at codesourcery dot com 2011-12-08 22:32:24 UTC ---
On Thu, 8 Dec 2011, lucier at math dot purdue.edu wrote:
> Indeed, I couldn't find a place in the gcc sources where this macro was
> used:
>
> hei
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #5 from joseph at codesourcery dot com 2011-12-20 22:34:43 UTC ---
On Tue, 20 Dec 2011, sipych at gmail dot com wrote:
> "On platforms that do not support dynamic pre-emption of symbols an unresolved
> weak reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997
--- Comment #4 from joseph at codesourcery dot com 2011-12-22 12:53:39 UTC ---
On Thu, 22 Dec 2011, pinskia at gcc dot gnu.org wrote:
> I think we encode proligue and epilogues now for all targets.
It's been done for several targets,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730
--- Comment #2 from joseph at codesourcery dot com 2012-01-02 13:03:35 UTC ---
On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:
> char digs[] = "0123456789";
> int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #5 from joseph at codesourcery dot com 2012-01-06 11:47:15 UTC ---
On Fri, 6 Jan 2012, redi at gcc dot gnu.org wrote:
> does glibc also define macros for alignof, true, false, bool etc. in C++ mode?
Those C11 macros are defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #7 from joseph at codesourcery dot com 2012-01-06 15:28:16 UTC ---
On Fri, 6 Jan 2012, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
>
> --- Comment #6 from Jonathan Wakely 2012-01-06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #10 from joseph at codesourcery dot com 2012-01-06 15:51:20 UTC ---
On Fri, 6 Jan 2012, jakub at gcc dot gnu.org wrote:
> I'm not sure if for -D_GNU_SOURCE we want a ::gets prototype in C++, it would
> be better to ju
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #42 from joseph at codesourcery dot com 2012-01-09 22:51:04 UTC ---
The obvious issue with C++11 attributes (such as [[noreturn]]) is that the
syntactic bindings are (or were when I last looked at a draft)
incompatible with the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #28 from joseph at codesourcery dot com 2012-01-12 14:35:58 UTC ---
On Thu, 12 Jan 2012, rguenther at suse dot de wrote:
> > I think extern inlines are sadly rather common to be deprecated...
>
> Well, not deprecating ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
--- Comment #10 from joseph at codesourcery dot com 2012-01-27 23:12:38 UTC ---
I don't think the test programs here are strictly conforming - the offset
could be bigger than the alignment, and alignments are values
"representing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
--- Comment #11 from joseph at codesourcery dot com 2012-01-27 23:26:39 UTC ---
I should add: as a matter of ABI compatibility with programs doing what
stddef.h does for max_align_t (double fields using
__attribute__((__aligned__(__alignof__
--- Comment #4 from joseph at codesourcery dot com 2007-05-02 12:58 ---
Subject: Re: Invalid assembly code on initial dollar signs
On Wed, 2 May 2007, truedfx at gentoo dot org wrote:
> Thanks for the link. I don't see how GAS could be fixed, though. How would the
> ass
--- Comment #4 from joseph at codesourcery dot com 2007-05-04 12:00 ---
Subject: Re: gcc segfaults on very long pointer chains
On Fri, 4 May 2007, bangerth at dealii dot org wrote:
> But seriously, while I do think that we should strive to compile even
> programs that are &quo
--- Comment #139 from joseph at codesourcery dot com 2007-05-23 21:00
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Wed, 23 May 2007, mark at codesourcery dot com wrote:
> Of course, Gaby's memory model doesn
--- Comment #2 from joseph at codesourcery dot com 2007-06-02 20:09 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
> Is this a parser problem? Compilation fails even for generic:
>
> --cut here--
> typedef
--- Comment #4 from joseph at codesourcery dot com 2007-06-02 21:35 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, gdr at cs dot tamu dot edu wrote:
> | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the
> | possible sets o
--- Comment #1 from joseph at codesourcery dot com 2007-06-05 00:07 ---
Subject: Re: New: License for libiberty
See <http://gcc.gnu.org/ml/gcc/2003-06/msg01286.html>; I don't recall
seeing the SC's/FSF's answer to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213
--- Comment #17 from joseph at codesourcery dot com 2007-06-13 11:30
---
Subject: Re: Paranoia UCB GSL TestFloat libm tests fail
- accuracy of recent gcc math poor
I previously suggested to the crlibm authors that they consider assigning
it to the FSF for contribution to libgcc
--- Comment #1 from joseph at codesourcery dot com 2007-06-14 23:26 ---
Subject: Re: New: ICE on valid code
On Thu, 14 Jun 2007, edmar at freescale dot com wrote:
> Gcc version 4.2.0 configured for e500v2, i.e.:
> --target=powerpc-unknown-linux-gnuspe --enable-e500_double
&g
--- Comment #22 from joseph at codesourcery dot com 2007-06-15 22:43
---
Subject: Re: Paranoia UCB GSL TestFloat libm tests fail
- accuracy of recent gcc math poor
On Fri, 15 Jun 2007, rob1weld at aol dot com wrote:
> This is just one number. How many more could there be, how w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456
--- Comment #2 from joseph at codesourcery dot com ---
If the implementation were not in this source file at all and no LTO were
used, it would be unambiguous that such an out-of-line implementation
would not be used when GCC knows how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 12 Dec 2018, msebor at gcc dot gnu.org wrote:
> I find the POSIX requirement to fail when n is greater than INT_MAX to be in
> conflict with C. I've submitted a de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #1 from joseph at codesourcery dot com ---
I'd argue that the constraint "The type of the entity to be initialized
shall be an array of unknown size or a complete object type that is not a
variable length array type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88477
--- Comment #3 from joseph at codesourcery dot com ---
I'm referring to C17 6.7.9#3, in the constraints for initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88479
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 13 Dec 2018, vincent-gcc at vinc17 dot net wrote:
> The C standard would have to drop ones' complement and sign-magnitude first.
And there's substantial support for do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 14 Dec 2018, rguenther at suse dot de wrote:
> Note I do not think the C standard is sufficiently clear with regarding
> to restrict qualified pointers loaded from memory.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88525
--- Comment #1 from joseph at codesourcery dot com ---
I'd say the enum member a is declared by a contained struct-declaration,
not by the declaration itself.
The case of reading the text to allow for a declarator inside a
struct-declar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88526
--- Comment #1 from joseph at codesourcery dot com ---
Types with [*] are definitely complete types; the standard explicitly says
"such arrays are nonetheless complete types". The "'[*]' not in a
declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88556
--- Comment #2 from joseph at codesourcery dot com ---
For any vaguely recent GCC version, the now-removed code in
bits/mathinline.h used __builtin_expm1l.
The key features for this (and much the same applies to the hypot / asinh
/ acosh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
--- Comment #1 from joseph at codesourcery dot com ---
On Sat, 22 Dec 2018, bugzi...@poradnik-webmastera.com wrote:
> In test() gcc is not able to determine that for a==b it does not have to
> evaluate 2nd comparison and can use value o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88582
--- Comment #4 from joseph at codesourcery dot com ---
The unqualified version of _Atomic int is _Atomic int; references to
qualified or unqualified versions of a type do not by default include the
type with _Atomic added or removed (see 6.2.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #6 from joseph at codesourcery dot com ---
This looks like a case that was missed in, or broken by, my fix for bug
13801, which was supposed to address such cases of entities with different
(compatible) types in different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88623
--- Comment #1 from joseph at codesourcery dot com ---
gcc/ is not libgcc. libgcc is only ever built using exactly the same
version of GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
--- Comment #1 from joseph at codesourcery dot com ---
6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an
incomplete type and does not have array type, the behavior is undefined.".
Cf. bug 36941 (noting how DR#10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #40 from joseph at codesourcery dot com ---
The definitions have been added for VxWorks at some point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88667
--- Comment #1 from joseph at codesourcery dot com ---
This is a known defect in the syntax in the standard, as discussed on the
WG14 reflector on 22 Sep 2017 (see reflector message 14798).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #16 from joseph at codesourcery dot com ---
On Thu, 3 Jan 2019, iains at gcc dot gnu.org wrote:
> Unfortunately, there doesn't appear to be anything in the GCC test suite that
> catches this (all languages reg-strap wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88674
--- Comment #1 from joseph at codesourcery dot com ---
"qualified" is used in the informal sense of "any additional specifiers
along with void", not in the sense of "type qualifiers present". The
program is not v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 4 Jan 2019, jakub at gcc dot gnu.org wrote:
> Joseph, is there any meaning for DECL_EXTERNAL & TREE_STATIC, or is that
> invalid flag combination? If the latter, we shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #5 from joseph at codesourcery dot com ---
It's DR#316 that's relevant here (where the committee agreed with my
interpretation that implies this example is valid, and reiterated their
intent not to fix issues with un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88700
--- Comment #2 from joseph at codesourcery dot com ---
Consensus in glibc is that Annex K is badly designed and should not be
supported at all. See
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm> proposing
obsoletion or removal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584
--- Comment #8 from joseph at codesourcery dot com ---
Yes, I consider this a confirmed (and, strictly, regression from 3.4) bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727
--- Comment #1 from joseph at codesourcery dot com ---
This was the case mentioned in bug 26581 comment 4, but without a separate
bug filed for it at the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88731
--- Comment #2 from joseph at codesourcery dot com ---
GCC makes the integer type of the bit-field in question "unsigned:4".
See DR#315 (also, see the line of C90 DRs that led to the wording changes
in C99 relating to types of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46495
--- Comment #2 from joseph at codesourcery dot com ---
On Tue, 8 Jan 2019, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46495
>
> Eric Gallager changed:
>
>W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #14 from joseph at codesourcery dot com ---
On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote:
> - binutils, with a linker configured to look for system libraries in a
> non-standard folder, empty for now
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425
--- Comment #4 from joseph at codesourcery dot com ---
<https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00284.html> has my comments
on ways in which libm functions can be "const/pure with exceptions". It
would be possible to ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
--- Comment #16 from joseph at codesourcery dot com ---
On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote:
> FYI, what I am following are the Linux From Scratch guidelines, which build
> the
> initial gcc like this (with b
601 - 700 of 2027 matches
Mail list logo
