https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #8 from joseph at codesourcery dot com ---
"." is correct for the default multilib in the non-OS directory
arrangements, just not in the OS directory arrangements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142
--- Comment #1 from joseph at codesourcery dot com ---
On Sat, 31 Mar 2018, david.abdurachmanov at gmail dot com wrote:
> GCC 7.3.1 is available in Fedora RISC-V stage4 and is configured with
> multilib,
> but only one ABI is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
--- Comment #17 from joseph at codesourcery dot com ---
And, when long is 64-bit, there is no corresponding standard function to
round to 32-bit integer with "invalid" raised for out-of-range results -
but there is (un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
--- Comment #16 from joseph at codesourcery dot com ---
These instructions use the current rounding mode, not round-to-zero.
That is, they correspond to the lrint / llrint functions, given
-fno-math-errno.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #38 from joseph at codesourcery dot com ---
I think the correct state is NEW. There is a well-defined set of target
OSes that lack the target macro definitions describing those targets'
stdint.h types, each of which should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #36 from joseph at codesourcery dot com ---
I don't think this bug meets the definition of WAITING.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 21 Mar 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> Joseph, any suggestions? You mentioned that older versions of glibc
> didn't provide 16-byte alignment in i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84997
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 21 Mar 2018, antoshkka at gmail dot com wrote:
> unsigned test02(unsigned lhs) {
> return lhs + 2.0; // No signed overflow
> }
If lhs is UINT_MAX or UIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84997
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 21 Mar 2018, rguenth at gcc dot gnu.org wrote:
> > That would need -fno-trapping-math, because if the addition results in a
> > double value larger than INT_MAX, u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85009
--- Comment #1 from joseph at codesourcery dot com ---
It's not obvious that this is a bug, in that _Atomic is syntactically a
qualifier, but excluded semantically for most purposes. In particular,
that conversion is permitted by ISO C, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84997
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 20 Mar 2018, antoshkka at gmail dot com wrote:
> For example
>
> int test2(int lhs) {
> lhs += 2.0;
> return lhs;
> }
That would need -fno-trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84996
--- Comment #3 from joseph at codesourcery dot com ---
Adding +0.0 and -0.0 produces +0.0 except in FE_DOWNWARD mode. I.e.,
optimizing away an addition of +0.0 requires -fno-signed-zeros (not the
default), as well as -fno-signaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84900
--- Comment #3 from joseph at codesourcery dot com ---
Yes, I'd consider this invalid code. Presumably there's some issue with
the GNU extension allowing casts of structs to the same type, whereby in
some cases it fails to make the result
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 one NaN part
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's im
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=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 18661-2:2015
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 static libm
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
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
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=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 test
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
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=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=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=standard, so
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=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=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=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=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
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
"volatile uint32_t *
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 Col
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=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 N el
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's
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
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 deal wit
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 but GCC's
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=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
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=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=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/2017
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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #12 from joseph at codesourcery dot com ---
https://sourceware.org/ml/libc-testresults/2017-q4/msg00460.html
shows GCC build failures on alpha, hppa, ia64, m68k, microblaze, sh,
tilegx, tilepro. (The cases where the GCC build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83397
--- Comment #3 from joseph at codesourcery dot com ---
DR#317 explicitly confirms that () is not a prototype in a function
definition.
It's not valid in ISO C to call a variadic function without a prototype in
scope. To the extent that GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #31 from joseph at codesourcery dot com ---
On Wed, 6 Dec 2017, glaubitz at physik dot fu-berlin.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
>
> --- Comment #30 from John Paul Adrian Glaubitz fu-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #29 from joseph at codesourcery dot com ---
I don't see the issue building glibc with build-many-glibcs.py any more,
hence it no longer uses -fno-isolate-erroneous-paths-dereference
-fno-isolate-erroneous-paths-attribute for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #3 from joseph at codesourcery dot com ---
FWIW, current glibc already uses signed int for int32_t (via using it for
__int32_t which is used to define int32_t), entirely as an accident
following a header refactoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #1 from joseph at codesourcery dot com ---
I'm not aware of a standard requirement not to use plain int for int32_t
(even with unsigned bit-fields), though it may well be useful to make the
signedness explicit. After all, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186
--- Comment #6 from joseph at codesourcery dot com ---
For C, what is supposed to happen is that every call to groktypename where
there might be side effects from the type name passes a non-null EXPR
argument, and then the caller arranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194
--- Comment #3 from joseph at codesourcery dot com ---
You definitely cannot assume strcmp (s, t) == -strcmp (t, s), only that
the result has the correct sign in each case.
There should be no need to preserve the exact return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #18 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote:
> In the testcase, there is nothing that violates ABI. It all happens in "g"
> that
> passes calculated result to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> > It's valid to call a function in another file compiled with another
> > compiler that follows the ABI,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #5 from joseph at codesourcery dot com ---
Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
DF) undefined on function entry and return. Thus, a function can never
assume anything about the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83060
--- Comment #6 from joseph at codesourcery dot com ---
I'd say for C it's valid to reject [-1] and [__PTRDIFF_MAX__] in
static initializers, because there is no guarantee that such addresses are
valid values of the pointer type (only pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997
--- Comment #5 from joseph at codesourcery dot com ---
Jakub's patch is
<https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01041.html>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82946
--- Comment #2 from joseph at codesourcery dot com ---
On Sat, 11 Nov 2017, msebor at gcc dot gnu.org wrote:
> other string literal) cannot be a valid representation of a pointer. (The
> only
> way for a conforming program to obtai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 8 Nov 2017, tydeman at tybor dot com wrote:
> /*
> * C standard appears to be unclear on scope of new type defined in
> * offsetof() macro. Some compilers accept; so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272
--- Comment #4 from joseph at codesourcery dot com ---
I should point out that expanding to the tokens 0 and 1 for C does not in
any way prevent warning (it's a perfectly reasonable optional style
warning); you could for example have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82861
--- Comment #1 from joseph at codesourcery dot com ---
Should already have been fixed by r254277.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #7 from joseph at codesourcery dot com ---
As far as I understand the general state of DFP support in GCC: the basic
functionality generally works without needing much maintenance, but no-one
is actively fixing DFP bugs or updating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78829
--- Comment #4 from joseph at codesourcery dot com ---
_Alignof is alignment requirement (in all contexts), __alignof__ is
preferred alignment (so on 32-bit x86, for long long they are 4 and 8
respectively, because a long long in a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #34 from joseph at codesourcery dot com ---
None of the other preprocessor maintainers have commented on this bug in
the past four years to disagree with my view of the natural identification
of the current line for this __LINE__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #32 from joseph at codesourcery dot com ---
The evidence from the DR discussion is that it's the *less* portable
interpretation - that none of the implementations tested behaved as you
suggest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #30 from joseph at codesourcery dot com ---
An option to use just the file's basename in __FILE__ is bug 82176. I
think that's a much more reasonable feature than straining the
interpretation of what counts as the line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 25 Oct 2017, keno at juliacomputing dot com wrote:
> First, the build process looking for the headers in /sys-include rather
> than /include where glibc installs them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #5 from joseph at codesourcery dot com ---
The expectation for bootstrapping such a cross toolchain is that GCC is
configured and built twice. The first build is static-only, C-only,
inhibit-libc, disables lots of libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #3 from joseph at codesourcery dot com ---
That's not the test I'm talking about. The relevant one is
gcc/Makefile.in's LIMITS_H_TEST, run during a build stage rather than a
configure stage, so you need to look at the setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #1 from joseph at codesourcery dot com ---
If you have correctly configured GCC so that it can find the system
headers at configure time, include-fixed/limits.h should be constructed as
a concatentation of limitx.h, glimits.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #28 from joseph at codesourcery dot com ---
Well, I also think the existing choice is the more natural choice for the
value of __LINE__ in this case (#line is mainly for use by code
generators, which can always count lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679
--- Comment #5 from joseph at codesourcery dot com ---
Probably in grokdeclarator the test for _Atomic-qualified array types
should check declspecs->atomic_p rather than atomicp. (The check in the
parser in the case of _Atomic (type-n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #13 from joseph at codesourcery dot com ---
Strictly, all x86 excess precision cases are indeterminable (semantics of
-1) except for the case where -fexcess-precision=standard is used
(requires front-end support, present for C only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #2 from joseph at codesourcery dot com ---
I think a value of 0 should be correct with -mfpmath=sse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #6 from joseph at codesourcery dot com ---
glibc does not use this option. ABI checking in glibc works on binaries
via objdump -T. linknamespace tests do use -aux-info to list functions
exported by a header, and would find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #8 from joseph at codesourcery dot com ---
The algorithm isn't expecting to use FMA; it's just treating
floating-point numbers as approximate real numbers. I'm not sure why
multiplication has TRUNC, but my guess is it's about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
--- Comment #2 from joseph at codesourcery dot com ---
In my view, a separate option for this warning rather than
-Wincompatible-pointer-types would be best (as it's much more likely
people will want to disable this warning than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429
--- Comment #2 from joseph at codesourcery dot com ---
Strictly, that a program declares stpcpy should be irrelevant if the
declaration is outside system headers, because it could declare and define
it for some other purpose (even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82390
--- Comment #5 from joseph at codesourcery dot com ---
dg-options is absolutely fine in torture directories, as long as the
options specified are not among the -O options that the test should be
looping over. For example, it's fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #4 from joseph at codesourcery dot com ---
I think the glibc reasoning is: libm functions do not need to behave as if
written in standard C, so in particular F.6 does not apply to them and
they may return values with excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272
--- Comment #1 from joseph at codesourcery dot com ---
I think they do have to expand to the tokens 0 and 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 12 Sep 2017, vsevolod.livinskij at frtk dot ru wrote:
> struct struct_t {
> unsigned int memb : 13;
> };
>
> extern struct_t b;
> printf("%llu\n&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 12 Sep 2017, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
>
> --- Comment #4 from Vincent Lefèvre ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
--- Comment #2 from joseph at codesourcery dot com ---
The documentation explicitly says -Wpedantic includes some warnings about
things outside of ISO C, beyond those that violate syntax rules or
constraints. (Sometimes this only applies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82158
--- Comment #2 from joseph at codesourcery dot com ---
Falling off a noreturn function sounds like it could be another case to
insert __builtin_trap (), as we do in various cases of undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82153
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 8 Sep 2017, arjan at linux dot intel.com wrote:
> When a conversion is inexact, a truncated result is returned. If a converted
> result is larger than the maximum signed doub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82153
--- Comment #1 from joseph at codesourcery dot com ---
floor rounds towards -inf. Conversion to int rounds towards 0. That is,
it wouldn't be valid to omit the roundsd because results would be
different for integer arguments. That said
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 1 Sep 2017, aaro.koskinen at iki dot fi wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
>
> --- Comment #2 from Aaro Koskinen ---
> (In reply to Eric B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82051
--- Comment #3 from joseph at codesourcery dot com ---
On Thu, 31 Aug 2017, zwzhangwen.zhang at huawei dot com wrote:
>volatile long long f1;
> printf ("g_121.f1=%x\n",g_121.f1);
In addition to the other points people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #11 from joseph at codesourcery dot com ---
(That's essentially what the generic C implementation of rint in glibc
does. I make no assertions about whether inlining this long expansion of
rint for SSE, or even the shorter -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #10 from joseph at codesourcery dot com ---
A correct (for -frounding-math) SSE sequence would (for arguments with
absolute value < 2**52) add and subtract 2**52 for a positive operand,
-2**52 for a negative operand. Then it wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #17 from joseph at codesourcery dot com ---
Presumably the bit-field issue is RX defaulting to MS bit-field layout
(rx_is_ms_bitfield_layout suggests making the structure itself packed
should help).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #13 from joseph at codesourcery dot com ---
fp-bit != soft-fp. soft-fp always uses bit-fields (with the order
depending on the endianness). It's possible that in some cases you need
to ensure the declared types of the bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81801
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 11 Aug 2017, oss at malat dot biz wrote:
> One could solve it by dividing both pointers by the size before the
> subtraction, but that would make the operation more expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81686
--- Comment #3 from joseph at codesourcery dot com ---
The hook is specified to take an input that's in the basic source
character set ($ is also used with it). Maybe LTO should store the
complete mapping for basic source characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:
> If there is a concern that the attribute could be used on declarations in
> existing code that the optimization might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
--- Comment #6 from joseph at codesourcery dot com ---
On Wed, 2 Aug 2017, chris.ol...@iti-global.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
>
> --- Comment #4 from chris.ol...@iti-global.com ---
> (In
501 - 600 of 2017 matches
Mail list logo
