https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #18 from joseph at codesourcery dot com ---
On Wed, 4 Sep 2019, tnfchris at gcc dot gnu.org wrote:
> As far as I am aware, the final version of the patch had no regressions for
> any
> target, including PowerPC which I use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #13 from joseph at codesourcery dot com ---
These functions have to be expanded inline, unconditionally; there are no
library functions they can reliably fall back on in general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90175
--- Comment #2 from joseph at codesourcery dot com ---
On Wed, 28 Aug 2019, jozefl.gcc at gmail dot com wrote:
> As far as I understand, strings which get passed to warning() or error() or
> other functions with arguments ending in gmsgid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
--- Comment #2 from joseph at codesourcery dot com ---
https://gcc.gnu.org/ml/gcc-patches/2009-10/msg01016.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91526
--- Comment #7 from joseph at codesourcery dot com ---
There's more or less the same ABI question as in bug 91398 about whether
there is any constraint on the called function writing to the return value
slot in cases where it does not return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #8 from joseph at codesourcery dot com ---
A more general representation would facilitate implementing
__builtin_iseqsig (bug 77928).
(As noted in previous discussions, some processors, e.g. MIPS, actually
have a general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595
--- Comment #3 from joseph at codesourcery dot com ---
The score port was removed in 2014. All open bugs for it should have been
closed at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
--- Comment #1 from joseph at codesourcery dot com ---
ABI question: is a function that returns a value through such a hidden
pointer required not to write anything to the storage pointed to until it
knows that it will definitely be returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #5 from joseph at codesourcery dot com ---
It's *accessible objects* whose value on second return from setjmp is the
same as when longjmp is called (unless non-volatile, automatic storage
duration and changed between setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #18 from joseph at codesourcery dot com ---
I don't expect people to do such comparisons with addresses of local
variables directly. It is plausible that they have a memmove-like
function, and once it gets inlined the compiler can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #30 from joseph at codesourcery dot com ---
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
is the form to complete and send to ass...@gnu.org (to do an assignment
covering past and future
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88451
--- Comment #6 from joseph at codesourcery dot com ---
I don't think anyone has really been maintaining the fixed-point support
for a very long time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91285
--- Comment #4 from joseph at codesourcery dot com ---
Note that all the standard C pragmas are even more restricted than GCC's
statement-like pragmas - the standard pragmas (which aren't implemented in
GCC) are defined by the C standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #16 from joseph at codesourcery dot com ---
I think the most likely case for code using such comparisons is not a
mistake, but code doing something like memmove - code that checks whether
two arrays overlap, and which one comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #28 from joseph at codesourcery dot com ---
On Mon, 22 Jul 2019, lhyatt at gmail dot com wrote:
> I am interested in helping out with this if there is still interest to support
> this feature. (Full disclosure, I don't ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226
--- Comment #1 from joseph at codesourcery dot com ---
This appears to be a bug in libdecnumber/bid/bid2dpd_dpd2bid.c.
_bid_to_dpd32 checks for a too-large significand, but _bid_to_dpd64 does
not. Furthermore, _bid_to_dpd128 has the same bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #3 from joseph at codesourcery dot com ---
There is a known ambiguity in the standard requirements where the argument
has the correct promoted type but not the expected type before promotion.
I wrote up some notes on this some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #32 from joseph at codesourcery dot com ---
I concur that passing CL_DRIVER instead of CL_LANG_ALL is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #13 from joseph at codesourcery dot com ---
As I noted in bug 40883 comment 8, you can detect such issues in
target-specific code by building a cross compiler using a native compiler
from the same trunk version, and configuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
--- Comment #11 from joseph at codesourcery dot com ---
Discussions of the change continued into Aug / Sep 2017. In particular,
there were issues with warnings this introduced in the GCC build (of
target libraries), and questions about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91046
--- Comment #3 from joseph at codesourcery dot com ---
There can't be any debug info issues specific to empty translation units,
given that
_Static_assert (1, "");
is valid as a translation unit in ISO C, and doesn't declar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #12 from joseph at codesourcery dot com ---
On Thu, 1 Aug 2019, ubizjak at gmail dot com wrote:
> It also means that __builtin_islessgreater is confusingly named.
No, __builtin_islessgreater corresponds to the ISO C islessgrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90993
--- Comment #2 from joseph at codesourcery dot com ---
Note that this is only valid with -fno-trapping-math (since integer
division is not permitted to raise the "inexact" exception flag). (With
AVX-512 there are instructio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 24 Jun 2019, rguenth at gcc dot gnu.org wrote:
> so I guess it differs from -frounding-math also in a way that it doesn't
> guard FENV access of the exception state (I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #9 from joseph at codesourcery dot com ---
When using "build-many-glibcs checkout" to check out the source
tree, you need to specify "gcc-vcs-mainline" after "checkout" to get GCC
trunk sources chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #3 from joseph at codesourcery dot com ---
No idea. I ran all-languages builds for all glibc ABIs as a one-off when
adding the --full-gcc option to build-many-glibcs.py, and reported the GCC
bugs that showed up. The idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68489
--- Comment #6 from joseph at codesourcery dot com ---
I'm not sure about arrays of structs, but glibc uses [0] at end of struct
in some cases where proper flexible array members would not be accepted.
E.g.
struct __gconv_info
{
size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #41 from joseph at codesourcery dot com ---
It's likely that caring about exceptions would actually be worse for
optimization than caring about rounding modes (because exceptions mean
that floating-point operations can write global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
--- Comment #8 from joseph at codesourcery dot com ---
Given how often such issues are in target-specific code, for targets that
only get built as cross compilers, in practice we'll need someone building
for all architectures *using a native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
--- Comment #17 from joseph at codesourcery dot com ---
The copy attribute is intended to copy attributes that are properties of
the function itself (e.g. "pure"), but not those that are properties of a
particular symbol for the fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90472
--- Comment #3 from joseph at codesourcery dot com ---
This is not a bug.
If 'i' is not redeclared in an intermediate scope, so the visible
declaration is one at file scope, the rule that "if the prior declaration
specifies int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #14 from joseph at codesourcery dot com ---
That wording is long including several examples. You can see it in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf subclause
6.7.2.1 (C99 + TC1 + TC2 + TC3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90298
--- Comment #3 from joseph at codesourcery dot com ---
This is not redundant; the point is to convert -0 to +0.
Most of the libquadmath code is generated automatically from glibc sources
by substitutions done by update-quadmath.py (and most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #8 from joseph at codesourcery dot com ---
I have not been tracking the state of review or lack thereof for these
patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081
--- Comment #9 from joseph at codesourcery dot com ---
On Thu, 18 Apr 2019, harald at gigawatt dot nl wrote:
> > I think expanding the macro to its argument is clearly correct here,
> > including for UINT8_C, as the interpretati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081
--- Comment #7 from joseph at codesourcery dot com ---
On Sat, 13 Apr 2019, bafap5 at yahoo dot com wrote:
> int x = sizeof ((int8_t) 5); /* Correct, gives 1 */
> int y = sizeof (INT8_C(5)); /* Incorrect, gives 4 */
No, INT8_C(5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 5 Apr 2019, tom at honermann dot net wrote:
> To be clear, the position I'm suggesting is that we add support for something
> like these:
We (GCC) don't control printf; the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032
--- Comment #6 from joseph at codesourcery dot com ---
I don't have anything further to add on this issue. If you want a
docstring relicensing review you should say so when submitting a patch;
for other cases of relicensing not covered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89734
--- Comment #1 from joseph at codesourcery dot com ---
This doesn't need typeof. The following much simpler test demonstrates
this regression.
typedef const int CI;
CI f (void);
const int f (void);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 15 Mar 2019, rick at regreer dot net wrote:
> But can you explain why:
>
> static char *foo[] = { (char []){"this compiles ..."} };
>
> void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #7 from joseph at codesourcery dot com ---
The relation definitely is not transitive (so you can't declare the same
function to return two different enum types, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 14 Mar 2019, rguenther at suse dot de wrote:
> I see. This means the different cases in the testcase in question are
> not equivalent (when excess precision is involved) an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957
--- Comment #4 from joseph at codesourcery dot com ---
Well, I suppose you could have a new option to say what set of fixed
headers to use, in the case where your sysroot is not based on the one
used when building GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89667
--- Comment #2 from joseph at codesourcery dot com ---
Or if for some reason you need an array of pointers to writable strings,
you can use e.g. (char []) { "foo" }, a compound literal, as the
initializer for such a pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 11 Mar 2019, rguenth at gcc dot gnu.org wrote:
> > I wouldn't expect such a cast to be generated on the result of the
> > multiplication; I'd expect long double to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86655
--- Comment #9 from joseph at codesourcery dot com ---
On Mon, 4 Mar 2019, emsr at gcc dot gnu.org wrote:
> Also, the legendre functions should not be onstrained on the argument x
> either.
> They are just polynomials. The r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673
--- Comment #6 from joseph at codesourcery dot com ---
On Tue, 12 Mar 2019, luoxhu at cn dot ibm.com wrote:
> Actually this was introduced by the initial patch
> https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00330.html committed in 2005.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89573
--- Comment #2 from joseph at codesourcery dot com ---
On Mon, 4 Mar 2019, rguenth at gcc dot gnu.org wrote:
> where the first result is off. The IL looks like
>
> int r = (int) ((long double) log (p) * (long double) inv_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #30 from joseph at codesourcery dot com ---
At the point where the then block starts being processed (and, thus,
warnings may be given) it wouldn't be known whether there are labels in
there or not; cf. the discussion in bug 68193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #4 from joseph at codesourcery dot com ---
In fact, having tested it, and used static linking to make sure the new
libquadmath was used rather than an older distribution version, this bug
was fixed in GCC 8, presumably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #1 from joseph at codesourcery dot com ---
Are you sure you're using (at runtime) the libquadmath from the GCC
version you're using (via -rpath / LD_LIBRARY_PATH, or linking with static
rather than shared libquadmath), rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #3 from joseph at codesourcery dot com ---
GCC 8 branched off mainline in April 2018, long before that merge; it's
necessary to test mainline (that will become GCC 9 and later), not any
existing release, to see if that merge fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #1 from joseph at codesourcery dot com ---
Please see whether this still applies with GCC mainline (postdating my
2018-11-07 merge of fmaq changes from glibc which brought in at least one
bug fix).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=704
--- Comment #18 from joseph at codesourcery dot com ---
Whether this is fixed may be determined by running all of the programs
installed in $exec_prefix/bin by current mainline with the --help and
--version options (and confirming the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 19 Feb 2019, marxin at gcc dot gnu.org wrote:
> Before the revision it was rejected with:
>
> atomic2.c: In function ‘func’:
> atomic2.c:49:8: error: x87 register ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89175
--- Comment #3 from joseph at codesourcery dot com ---
See bug 27682.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #10 from joseph at codesourcery dot com ---
My interpretation of that footnote is that it's observing that there is no
way within the standard to *create* linkage between different identifiers
- not that it constrains how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 30 Jan 2019, egallager at gcc dot gnu.org wrote:
> So can this be closed then?
A change *in C11 mode* has nothing to do with possible imprecision of the
wording of a diagnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #22 from joseph at codesourcery dot com ---
A large proportion of the glibc libm tests still segfault for
powerpc-linux-gnu soft-float with that patch applied to GCC trunk.
(Although I don't see nextafter tests among those falling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #8 from joseph at codesourcery dot com ---
The Arm rule is that the EH machinery needs to avoid using VFP (or other
non-core) registers so that the unwinder can save them on-demand only.
See
<http://infocenter.arm.com/help/to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
--- Comment #1 from joseph at codesourcery dot com ---
Guessing this might be another issue from pushdecl being called for
compound literals (r259641).
(Technically of course it's true that the jump misses the initialization
of the anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89052
--- Comment #2 from joseph at codesourcery dot com ---
I'd say it's a bug for GCC to need to allocate memory for the trailing
zero-initialized part of such an object at all; it should only need to
allocate memory for the initial part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89043
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 24 Jan 2019, msebor at gcc dot gnu.org wrote:
> The CHANGE HISTORY section for stpcpy says the function was first released in
> Issue 1 and derived from Issue 1 of the SVID:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
--- Comment #20 from joseph at codesourcery dot com ---
r261797 removed all references to _ANSI_H_ from stddef.h, so this issue
can't be relevant after then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #10 from joseph at codesourcery dot com ---
Use of stfs on a double-precision value without frsp first is worse than
simply using the wrong rounding mode; in the case of overflow it does a
bitwise defined operation which is pretty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88822
--- Comment #1 from joseph at codesourcery dot com ---
If an rvalue's type (or, for that matter, an lvalue's type) is observed
with _Generic, the qualifiers should be consistently dropped.
If a type is observed with typeof, qualifiers need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774
--- Comment #1 from joseph at codesourcery dot com ---
Although the wording is different in the two cases (and the rule for
return types is newer), I think qualifiers on function parameters should
be considered as not part of the type just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 9 Jan 2019, msebor at gcc dot gnu.org wrote:
> I don't disagree with the conclusion about the validity of this test case but
> there are examples where GCC does treat a sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
--- Comment #4 from joseph at codesourcery dot com ---
Errors for infinite arguments to math.h functions are generally documented
in Annex F; 7.12.1 just says "an implementation may define additional
domain errors, provided that such e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #2 from joseph at codesourcery dot com ---
Yes, I think that (a) a statement expression is not an lvalue and (b) if
it were (or if the code were changed to move the unary '&' inside the
statement expression), the code w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
--- Comment #2 from joseph at codesourcery dot com ---
Note that there are also such cases as
static int x;
struct s { int a[sizeof(x)]; } inline *f (void) { return 0; }
where the reference to x is part of the return type (still syntactically
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 (wi
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
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=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=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=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=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=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=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 unprototyped
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
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 no
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 was
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=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=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=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=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=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=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
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=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=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-declaration
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=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 doing
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=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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88382
--- Comment #2 from joseph at codesourcery dot com ---
The extension is intentionally supported. Thus, it should be documented.
301 - 400 of 2017 matches
Mail list logo
