https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88362
--- Comment #6 from joseph at codesourcery dot com ---
On Wed, 5 Dec 2018, msebor at gcc dot gnu.org wrote:
> so that we get consistent behavior for reference members. __alignof__ should
> return the corresponding alignment. For e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88362
--- Comment #4 from joseph at codesourcery dot com ---
It's not very clear to me what an aligned attribute on a reference, or a
check of the alignment of a reference, should mean anyway.
Note that in some places, [[]]-style attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
--- Comment #8 from joseph at codesourcery dot com ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> The glibc commit that triggered this bug is:
> bfff8b1becd7d01c074177df7196ab327cd8c844
That's the copyright date u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #6 from joseph at codesourcery dot com ---
A format attribute for syslog is bug 15338.
(A fully general system for extensible format checking is hard, as I think
it would be a bad idea for it effectively to turn the internals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #2 from joseph at codesourcery dot com ---
The -Wformat -Wpedantic comment should warn for nonstandard formats - but
would do so for all format functions, not a subset. And while we have
separate printf and gnu_printf arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
--- Comment #3 from joseph at codesourcery dot com ---
As of October 2017, glibc has a testcase that having main in a shared
library works - that's a valid use case, which should work with crt1.o.
If it doesn't work for some particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
--- Comment #12 from joseph at codesourcery dot com ---
This seems a reasonable enough example for punning to me, given that all
accesses are via the union type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
--- Comment #10 from joseph at codesourcery dot com ---
On Wed, 28 Nov 2018, rguenth at gcc dot gnu.org wrote:
> Hmm, OTOH the C standard specifies that the store to u.b.b makes it the
> u.b the active member and it makes the old co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #7 from joseph at codesourcery dot com ---
As discussed, the load instructions should never raise underflow
exceptions, and having traps enabled for the nonstandard denormal operand
exception is clearly outside the scope of what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #9 from joseph at codesourcery dot com ---
I'd suggest reviewing the set of files changed to see if any are generated
files, or their sources (configure.ac, aclocal.m4, etc.), and doing a
regeneration in that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
--- Comment #2 from joseph at codesourcery dot com ---
The earlier position is preferred because logically at the closing brace
the type should be fully defined and it should no longer be possible to
change properties of it through attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #4 from joseph at codesourcery dot com ---
An ordered comparison (< <= > >=) with qNaN raises the "invalid"
exception. An equality comparison (== !=) does not, and nor do
__builtin_isless etc.
I don't know h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 22 Nov 2018, pinskia at gcc dot gnu.org wrote:
> I think one of the reasons why it has not been removed is there is still code
> out there that uses this syntax.
Including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #23 from joseph at codesourcery dot com ---
And, yes, at least one extra bit in emin is needed for that sticky
rounding code to work (because the user's source code may have a decimal
constant that is slightly over half the least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #22 from joseph at codesourcery dot com ---
On Wed, 21 Nov 2018, rguenther at suse dot de wrote:
> /* Nonzero value, possibly overflowing or underflowing. */
> mpfr_init2 (m, SIGNIFICAND_BITS);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88097
--- Comment #5 from joseph at codesourcery dot com ---
As of glibc 2.28, glibc uses __builtin_bswap* when available on all
architectures.
commit 0d40d0ecba3b1e5b8c3b8da01c708fea3948e193
Author: Joseph Myers
Date: Tue Feb 6 21:55:08 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 20 Nov 2018, rguenth at gcc dot gnu.org wrote:
> if (fmt->emin < min_exp)
> min_exp = fmt->emin - fmt->p + 1;
> so somehow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #13 from joseph at codesourcery dot com ---
MPFR deals with larger exponent ranges for intermediate computations
itself (MPFR functions generally set the maximum possible exponent range
internally). MPC generally doesn't seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #12 from joseph at codesourcery dot com ---
Note that such issues are not unique to ctan.
E.g., compiling __builtin_jn (10, 1e10) will produce such a hang.
The difference is that in the ctan case the additional algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 19 Nov 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> However, there's another option: C11, 6.4.2.1 General, n.71 suggests
>
> On systems in which linkers cannot accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #7 from joseph at codesourcery dot com ---
Note there are a few places where it's "cannot",
which the most obvious find/sed might not locate. E.g. in lra-remat.c:
/* Map: insn -> candidate representing it. It is nul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68235
--- Comment #4 from joseph at codesourcery dot com ---
I'm not aware of any fix for this bug (the only commit shown is a change
to testcase options, not a fix).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684
--- Comment #8 from joseph at codesourcery dot com ---
I see no sign of Segher's patch to fix the bug (as opposed to some XFAILs
pending a fix) having been committed, and a trivial testcase still
generates fcmpu instructions with a compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88062
--- Comment #1 from joseph at codesourcery dot com ---
This is not a GCC bug. tgmath.h is provided by glibc, not GCC, and glibc
indeed does not yet include the type-generic macros for functions rounding
to a narrower type (nor does glibc yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
--- Comment #5 from joseph at codesourcery dot com ---
AT_FDCWD was added in glibc 2.4, released 2006-03-06.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769
--- Comment #6 from joseph at codesourcery dot com ---
If you want the modern process for building a cross toolchain for a
GNU/Linux (or GNU/Hurd) target, look at how glibc's build-many-glibcs.py
does it. (This is not saying you need to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87879
--- Comment #1 from joseph at codesourcery dot com ---
You'd need dataflow information that's not available at that point in the
front end to know that the initializer is indeed the value of fmt at that
point in the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83353
--- Comment #5 from joseph at codesourcery dot com ---
asin(sin(a)) is not safe (or at least not simple) because of arguments
outside [-pi/2, pi/2]. sin(asin(a)) is more appropriate with -ffast-math
because arguments outside [-1,1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #10 from joseph at codesourcery dot com ---
I was not attempting to confirm that GCC had a particular bug.
In this case: as I said, no excess precision support is hooked up for
decimal floating point (i.e., whatever the back end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 30 Oct 2018, mte.zych at gmail dot com wrote:
> ../gcc-source/configure --build=x86_64-linux-gnu \
> --host=x86_64-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
--- Comment #9 from joseph at codesourcery dot com ---
On Mon, 29 Oct 2018, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
>
> --- Comment #8 from Eric Gallager ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741
--- Comment #5 from joseph at codesourcery dot com ---
Send email issues to postmas...@sourceware.org (not overseers, that's
another mailing list on the same server).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
--- Comment #1 from joseph at codesourcery dot com ---
Note that you can have a custom malloc function (e.g. xmalloc) that pairs
with standard free, so it should be possible to indicate that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #9 from joseph at codesourcery dot com ---
I think it would be appropriate for the front end to generate something
for return ; that avoids this warning. I don't know whether
that should be a literal return of error_mark_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #7 from joseph at codesourcery dot com ---
If CC:ing me on a bug, please always state the specific question on which
you want an opinion; don't CC me simply because I maintain the relevant
part of the compiler (I read gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87593
--- Comment #1 from joseph at codesourcery dot com ---
Supporting format_arg for multiple arguments of a function isn't a mistake
or counter-intuitive at all. A correct declaration of the ngettext
function requires more than one format_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
--- Comment #3 from joseph at codesourcery dot com ---
Unless someone can identify a commit that deliberately fixed the bug *and
added appropriate tests to the testsuite*, I'd strongly advise adding
tests to the testsuite before marking FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87482
--- Comment #3 from joseph at codesourcery dot com ---
I expect it's valid to use (void) if that particular IFUNC resolver
doesn't use the HWCAP information passed, even if the HWCAP information is
passed to resolvers on that architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87482
--- Comment #1 from joseph at codesourcery dot com ---
Yes, on some platforms the resolver takes the HWCAP as an argument and so
should be declared as a function taking that argument (if it uses it,
anyway).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #26 from joseph at codesourcery dot com ---
On Thu, 27 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> > The interpretation of C99 rules for excess precision used in GCC has been
> > explained at length from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #22 from joseph at codesourcery dot com ---
6.3.1.8 specifies *types*. It only gives some partial information about
*evaluation formats*, which is essentially a consequence of information
elsewhere (it states the possibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #20 from joseph at codesourcery dot com ---
I think the statement in 6.3.1.8 is only observing a consequence of
specifications elsewhere, and stating that this excess range and precision
does not affect semantic types; it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #19 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> 6.3.1.5p2 is only about explicit conversions and function calls (otherwise,
> types are not demoted magically). But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #16 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
>
> --- Comment #14 from Vincent Lefèvre ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #13 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> But there are no differences with 6.3.1.4 (when converting to a floating
> type):
> in both cases, either the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #9 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
>
> --- Comment #8 from Vincent Lefèvre ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 26 Sep 2018, vincent-gcc at vinc17 dot net wrote:
> > It's 6.3.1.4 for conversions between real floating and integer types that,
> > in C99 but not C11, I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #5 from joseph at codesourcery dot com ---
It's 6.3.1.4 for conversions between real floating and integer types that,
in C99 but not C11, I think requires the resulting value to be
representable in the resulting real floating type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87392
--- Comment #7 from joseph at codesourcery dot com ---
The implementation-definedness of signed left shift in C90, including
shifting into or past the sign bit (as long as the shift count isn't too
large or negative), is stated explicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390
--- Comment #3 from joseph at codesourcery dot com ---
I believe this is correct for C99 (see the discussions in bug 82071): my
reading of C99 is that conversions of integers to floating point, both
explicit and implicit, produce results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87363
--- Comment #4 from joseph at codesourcery dot com ---
I think the *member* of the union here (the one that is active after the
initialization) is the anonymous struct containing x and y. That would
surely be the case if you named the two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87363
--- Comment #2 from joseph at codesourcery dot com ---
On Wed, 19 Sep 2018, msebor at gcc dot gnu.org wrote:
> Other than that, since
>
> When a value is stored in a member of an object of union type, the bytes of
> the object re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524
--- Comment #2 from joseph at codesourcery dot com ---
I believe the syntax in N2269 does allow [[]] attributes there (and
disallows them as prefixes on old-style parameters to avoid ambiguity) -
but they appertain to the function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87303
--- Comment #2 from joseph at codesourcery dot com ---
I don't see a bug here. Excess precision semantics mean that the
comparison is effectively with 0.1e-100L (whereas the array initializer is
(double) 0.1e-100L). If you use "!= (d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #9 from joseph at codesourcery dot com ---
On Sat, 8 Sep 2018, iains at gcc dot gnu.org wrote:
> 2. Actually, you get the same failure on GNU-Linux if you try to configure
> defaults on (for example) an x86_64 system without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87247
--- Comment #4 from joseph at codesourcery dot com ---
The standard branch cut for acosh (not just a C standard, but as at
https://dlmf.nist.gov/4.37 for example) follows from the principles that
(a) acosh(conj(x)) = conj(acosh(x)) and (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220
--- Comment #1 from joseph at codesourcery dot com ---
What does -fstack-clash-protection give? (-fstack-check is an old option
for specific Ada requirements; for proper stack-clash protection for all
languages you want -fstack-clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
--- Comment #2 from joseph at codesourcery dot com ---
On Mon, 3 Sep 2018, pjp at fedoraproject dot org wrote:
> As from the reply, it would be nice to have four options/features available
> from the compiler, from least to most perfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
--- Comment #1 from joseph at codesourcery dot com ---
There are lots of glibc strtod fixes that postdate the last merges of
strtod code to libquadmath. I don't know if any of them are relevant to
this issue, but merging in those fixes would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182
--- Comment #3 from joseph at codesourcery dot com ---
Host libbacktrace would need to use GCC's host zlib and target
libbacktrace would need to use GCC's target zlib for the same target
multilib (which would require appropriate dependencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57492
--- Comment #5 from joseph at codesourcery dot com ---
The example from comment#2 should require -funsafe-math-optimizations
(it's not correct if the pow call overflowed / underflowed but the ldexp
call doesn't).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87050
--- Comment #6 from joseph at codesourcery dot com ---
A replacement for MetaHTML is already available, we just need to switch to
using it.
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00176.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #3 from joseph at codesourcery dot com ---
This is Wjump-misses-init. Is this a request to make some other option
such as -Wall or -Wextra enable that option (rather than just -Wc++-compat
as at present)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #18 from joseph at codesourcery dot com ---
On Tue, 21 Aug 2018, jvg1981 at aim dot com wrote:
> intptr_t pVal = ((uintptr_t) p)/(sizeof *p);
> intptr_t qVal = ((uintptr_t) q)/(sizeof *q);
Note that this can be ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #4 from joseph at codesourcery dot com ---
Any unaligned access things that don't work for big-endian ARM are
probably fallout from the issues with big-endian NEON (NEON architectural
lane numbers are different from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86923
--- Comment #1 from joseph at codesourcery dot com ---
Isn't this bug 65855?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86857
--- Comment #2 from joseph at codesourcery dot com ---
A configure test can only test what sprintf does for the host, not for the
target, so this would always need to be a target hook.
Even with a hook, it would not surprise me if e.g. results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86808
--- Comment #1 from joseph at codesourcery dot com ---
Given that both tilegx and tilepro only support *-linux* targets and the
Linux kernel has removed support for those architectures, we might
consider obsoleting those ports (as previously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690
--- Comment #2 from joseph at codesourcery dot com ---
Please send patches (which should add a testcase to the GCC testsuite, and
be tested with the GCC testsuite with no regressions) to gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631
--- Comment #3 from joseph at codesourcery dot com ---
The relevant point is after do_compile calls lang_dependent_init. Since
PTRDIFF_TYPE is a string, it's a pain to do anything with it until after
the front end has set up tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631
--- Comment #1 from joseph at codesourcery dot com ---
On Sun, 22 Jul 2018, msebor at gcc dot gnu.org wrote:
> In ILP32 it sets the limit for the warning to LLONG_MAX which is greater than
> the value of PTRDIFF_MAX on the targer (the in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86598
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 20 Jul 2018, zhonghao at pku dot org.cn wrote:
> g++ rejects the above code:
You don't say what options you are using, or what compiler version; please
include that in future
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86396
--- Comment #2 from joseph at codesourcery dot com ---
You can't fold atof ("3.14") with -frounding-math because the result
depends on the rounding mode, or with -ftrapping-math (which is the
default) because it should rais
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
--- Comment #7 from joseph at codesourcery dot com ---
If you use __builtin_nansf128 (which returns _Float128) but __float128 is
long double, it's possible the implicit conversion from storing the result
of __builtin_nansq in y.value results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #13 from joseph at codesourcery dot com ---
Well, C90 TC1 adds (to the informative Annex listing undefined behavior)
the case of array subscripts being out of range even if they wouldn't be
simply based on the top-level object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221
--- Comment #1 from joseph at codesourcery dot com ---
The C17 specification for function return types says "function returning
the unqualified version of T", not "function returning the unqualified,
non-atomic version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> So - all process_options () option post-processing should go away and be moved
> to finish_options ()?
I think reducing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> Joseph, do you agree that the following shouldn't fail the compilation?
>
> > echo 'int main(){}' | gcc -S -x c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
--- Comment #1 from joseph at codesourcery dot com ---
Yes, this code needs to be fixed to avoid undefined overflow (if argnum >
INT_MAX / 10 || (argnum == INT_MAX / 10 && *fcp - '0' > INT_MAX % 10),
record that overflow has occu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85995
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 1 Jun 2018, vincent-gcc at vinc17 dot net wrote:
> Programmers normally use conditionals on '__STDC__' to ask whether
> it is safe to use certain features of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997
--- Comment #3 from joseph at codesourcery dot com ---
The requirements on array declarators apply before parameter arrays decay
to pointers; see DR#047 (which concerns the case of an incomplete element
type - not itself a constraint violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997
--- Comment #1 from joseph at codesourcery dot com ---
Well, that's a VLA before the decay to pointer type, and thus violates the
C90 constraint referenced in the diagnostic. So a diagnostic is obviously
required with -std=c90 -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85995
--- Comment #3 from joseph at codesourcery dot com ---
See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make",
"Undefining @code{__STDC__} when @option{-ansi} is not used." (and the
description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #11 from joseph at codesourcery dot com ---
On Mon, 28 May 2018, vincent-gcc at vinc17 dot net wrote:
> floating-point expression: Once a floating-point number has been converted
> into
> an integer type, the value of thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 25 May 2018, msebor at gcc dot gnu.org wrote:
> Beyond that, #defining macros that match known attributes to something else
> seems like asking for trouble. It even c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921
--- Comment #14 from joseph at codesourcery dot com ---
On Fri, 25 May 2018, gcc at mailinator dot com wrote:
> https://gcc.gnu.org/install/ doesn't say anything about make headers_install.
That's because it's not part of installing GCC, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85917
--- Comment #1 from joseph at codesourcery dot com ---
The difference between -std=gnu11 and -std=gnu17 is not meant to be
significant, since apart from the __STDC_VERSION__ change C17 is purely a
bug-fix version and so there are no other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 16 May 2018, cookevillain at yahoo dot com wrote:
> The Standard is supposed to be a formal specification of the language, so if
No, it isn't. It's for humans, who n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #1 from joseph at codesourcery dot com ---
This is an obviously perverse interpretation of the standard that is
inconsistent with the intent expressed explicitly if non-normatively in
6.7.6.3#18 ("The identifiers x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
--- Comment #1 from joseph at codesourcery dot com ---
Sounds like a regression if this is the case, since bpabi.h in GCC 7 does
include march=armv8-a in BE8_LINK_SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
--- Comment #8 from joseph at codesourcery dot com ---
On Sun, 6 May 2018, roland.illig at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
>
> --- Comment #3 from Roland Illig ---
> (In reply to Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38960
--- Comment #5 from joseph at codesourcery dot com ---
Since any non-const function can examine floating-point state, I'd expect
significant effects on code generation. (Whether this also applies to
asms depends on the architecture; some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85585
--- Comment #2 from joseph at codesourcery dot com ---
On Tue, 1 May 2018, peter at cordes dot ca wrote:
> The current strings + pointer-table implementation doesn't merge string
> literals where one string is a suffix of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #14 from joseph at codesourcery dot com ---
As I said in comment#10, I think the solution is to remove the specs
making -mieee-fp imply -lieee. (Principally the spec in gnu-user.h. I
don't think this should depend on what libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518
--- Comment #2 from joseph at codesourcery dot com ---
You still need some of the built-in functions for use with __float128 in
C++ when that has a different format from long double. It's the built-in
functions for types with the same format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #39 from joseph at codesourcery dot com ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
> Code which relies upon this feature to implement a C-style approximation to
> inheritance has been fairly common,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361
--- Comment #3 from joseph at codesourcery dot com ---
See the documentation of -std=, regarding base standards.
# The compiler can accept several base standards, such as @samp{c90} or
# @samp{c++98}, and GNU dialects of those standards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 11 Apr 2018, jason at gcc dot gnu.org wrote:
> The quoted passage in the documentation now reads
>
> ---
> Some machines never actually require alignment; they all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #20 from joseph at codesourcery dot com ---
I consider it part of the ABI that long long
__attribute__((__aligned__(__alignof__(long long, as in the definition
of max_align_t (and similarly in gnulib's max_align_t definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182
--- Comment #1 from joseph at codesourcery dot com ---
This is how static assertions are defined in C11, not a bug in GCC: it's a
constraint violation if the constant expression compares equal to 0,
regardless of the context in which
401 - 500 of 2017 matches
Mail list logo
