https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #43 from joseph at codesourcery dot com ---
The build-many-glibcs.py builds with mainline tools start 24 hours after
the previous such build finished (so the next one will start at 21:44 UTC
today; if all the build problems are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #58 from joseph at codesourcery dot com ---
With the latest build-many-glibcs.py build
<https://sourceware.org/ml/libc-testresults/2017-q4/msg00468.html>, using
GCC trunk r255614, ia64 fails with an ICE building libgcc, m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #75 from joseph at codesourcery dot com ---
As of GCC trunk r255655 I no longer see the GCC ICE building glibc for
m68k (instead there's a non-ICE glibc build problem as noted in
<https://sourceware.org/ml/libc-alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
--- Comment #10 from joseph at codesourcery dot com ---
Please file a separate bug for hppa, just as we have separate bugs for the
powerpc and s390 back end issues. Assuming hppa-hpux has working fenv.h,
failure on hppa is probably a back-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83585
--- Comment #3 from joseph at codesourcery dot com ---
return without a value in non-void functions is valid in C90 (only
undefined at runtime if the return value is used by the caller). C99 made
it a constraint violation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
--- Comment #17 from joseph at codesourcery dot com ---
There are certainly cases where something that is undefined at compile
time in ISO C (i.e. the undefinedness is a property of the program, not of
a particular execution path through the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
--- Comment #5 from joseph at codesourcery dot com ---
The standard syntax production for octal-escape-sequence (C11 6.4.4.4#1)
only allows one, two or three digits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83737
--- Comment #4 from joseph at codesourcery dot com ---
Most configurations (for which the libc used has a working stdint.h)
should probably be using use_gcc_stdint=wrap, so that GCC's stdint.h
includes libc's for hosted compilations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33167
--- Comment #7 from joseph at codesourcery dot com ---
"longest sequence of characters that can constitute the escape sequence"
resolves an ambiguity between alternative parses permitted by the syntax;
it doesn't need to dea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785
--- Comment #1 from joseph at codesourcery dot com ---
I suspect this has the same cause as bug 78459, bug 80863 and bug 83760,
all of which involve ICEs in maybe_record_trace_start for SH and the first
two of which mysteriously went away (but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800
--- Comment #4 from joseph at codesourcery dot com ---
Functions bound to IEEE operations, such as sqrt and fma, should be
correctly rounding for all IEEE floating-point types (so not IBM long
double) supported by glibc. However, there'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 15 Jan 2018, msebor at gcc dot gnu.org wrote:
> 1) How to annotate constant size buffers. I'd like to be able to express that
> a function requires a buffer of at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #11 from joseph at codesourcery dot com ---
Even rs6000 changes related to IEEE long double support are potentially
relevant to powerpcspe (not anything related to binary128 in VSX,
obviously, but more generic IEEE long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #22 from joseph at codesourcery dot com ---
What do the m68k maintainers think about the suggestion of backporting to
GCC 7 (and for that matter GCC 6)? This is a regression in the sense of
"libgcc used to build for ColdFire,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84166
--- Comment #1 from joseph at codesourcery dot com ---
It's not confused. It's saying that it's type-safe to convert
"uint32_t **" to "volatile uint32_t *const *", but not to convert it to
"vola
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #4 from joseph at codesourcery dot com ---
You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for
predictable results from double arithmetic on 32-bit x86. If you do that,
do you still see such a problem? If not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824
--- Comment #5 from joseph at codesourcery dot com ---
In the case most likely to appear in glibc, foo would be declared with the
nothrow attribute and __foo would be missing it. I see no reason not to
diagnose the other case as well, I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824
--- Comment #7 from joseph at codesourcery dot com ---
On Thu, 8 Feb 2018, msebor at gcc dot gnu.org wrote:
> Okay, that would make sense. But then what do you mean by "weak, alias,
> visibility attributes are expected to dif
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=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=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=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
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), r
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 by the
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
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=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=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 recur
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
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 pointer, in
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=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=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=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=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=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 cover
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 pr
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=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 interpretation
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=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 of
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=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
specif
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=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 n
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 g
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
{
s
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 was that
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=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 raise &
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 fu
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=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
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=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=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=86923
--- Comment #1 from joseph at codesourcery dot com ---
Isn't this bug 65855?
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 fro
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=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=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=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=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 de
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
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=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=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=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=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 "
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=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=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=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 that
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 explicit
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=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 t
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 #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 val
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 #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 #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 not
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 of
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=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=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 ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84298
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 9 Feb 2018, rguenth at gcc dot gnu.org wrote:
> The fix is to place a DECL_EXPR somewhere by the FE. We have some duplicates
> with similar issues.
Should c_fully_fold_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84366
--- Comment #3 from joseph at codesourcery dot com ---
All ordered comparisons (< <= > >=) with at least one argument NaN should
raise invalid, so it's indeed just one case of bug 58684.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #11 from joseph at codesourcery dot com ---
It's not technically required (at least for this issue and as regards C
standards conformance) simply because options such as -std=c99 / -std=c11
imply -fexcess-precision=standar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84407
--- Comment #2 from joseph at codesourcery dot com ---
Cf. bug 57245 (a similar bug for truncation from wider floating-point
types).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 16 Feb 2018, egallager at gcc dot gnu.org wrote:
> > powerpc failure of floating-point extensions to quiet signaling NaNs
> > (because loads implicitly extend from flo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84416
--- Comment #2 from joseph at codesourcery dot com ---
Ignoring weird targets (m32c...), there's no valid use for array indices
larger than size_t / ptrdiff_t (beyond I suppose any optimization effects
from knowing that the conversion o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #14 from joseph at codesourcery dot com ---
I'd expect any complete patch default to -fno-math-errno to add
-fmath-errno to all tests relating to errno setting by libm functions (so
that patch was incomplete for lack of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84475
--- Comment #3 from joseph at codesourcery dot com ---
Note that _REENTRANT is a no-op with glibc 2.25 or later unless you
specifically select an old standard version (in which case it's an alias
for _POSIX_C_SOURCE=199506L).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84516
--- Comment #2 from joseph at codesourcery dot com ---
See also bug 70733, another bug with these types being user-exposed for
bit-fields for C++. For C++ (unlike C), the existence of these types
internally in the compiler should never be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #10 from joseph at codesourcery dot com ---
As I said in https://sourceware.org/bugzilla/show_bug.cgi?id=22951#c2 I
think uses of -mieee-fp are cargo-culted just like those of -lieee. I
think the appropriate GCC fix is simply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #12 from joseph at codesourcery dot com ---
Programs linked with glibc 2.26 will continue to work as expected.
_LIB_VERSION has become a compat symbol, so it's newly linked programs
that can't set it any more (and in s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84717
--- Comment #4 from joseph at codesourcery dot com ---
The 'd' suffix, and the FLOAT_CONST_DECIMAL64 pragma, were in TR
24732:2009. Those features were not carried forward to the newer decimal
floating-point specification in TS 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035
--- Comment #6 from joseph at codesourcery dot com ---
Since we have docstring relicensing maintainers, I don't think this is an
issue now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #6 from joseph at codesourcery dot com ---
The response to C99 DR#315 says that for all the types not specifying
"signed" or "unsigned" explicitly, if an implementation accepts them as
bit-field types it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #2 from joseph at codesourcery dot com ---
I'm not sure what the C++ complex multiplication / division requirements
are here (for that matter, C doesn't seem to precisely define which NaN -
which value with at least on
801 - 900 of 2027 matches
Mail list logo
