https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94730
--- Comment #3 from joseph at codesourcery dot com ---
I'd suspect the code in finish_decl that deals with types determined from
array initializers ("For global variables, update the copy of the type
that exists in the binding."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
--- Comment #1 from joseph at codesourcery dot com ---
Note that glibc currently uses __attribute__ ((__optimize__
("-fno-stack-protector"))) (via a macro called inhibit_stack_protector)
for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #13 from joseph at codesourcery dot com ---
bpabi-lib.h is the existing mechanism for renaming libgcc2.c functions and
declaring them with __attribute__((pcs("aapcs"))). (But when causing more
such functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 17 Apr 2020, bugdal at aerifal dot cx wrote:
> No, GCC's treatment also seems to mess up bitfields smaller than int and fully
> governed by the standard (no implementation-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94600
--- Comment #7 from joseph at codesourcery dot com ---
The Arm AAPCS has detailed rules for operations on individual volatile
bit-fields, but not for this case where the whole struct is volatile and
the operation is on the whole struct. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392
--- Comment #3 from joseph at codesourcery dot com ---
I'm not sure the existing infinite loop removal is valid for any C
standard version. The C (C11 and later) rule against infinite loops only
applies when the loop is written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #7 from joseph at codesourcery dot com ---
Passing a variable-size struct or union by value to a non-nested function
seems very questionable (the function couldn't be declared with a matching
prototype), but perhaps that doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60846
--- Comment #9 from joseph at codesourcery dot com ---
Note that supporting on any given 32-bit architecture requires making a
choice of what the function-calling ABI should be for such types (and
corresponding complex types) as function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94338
--- Comment #3 from joseph at codesourcery dot com ---
It's a mistake to be referring to the C standard for the interpretation of
alignment attributes. The C standard way of specifying alignment is
_Alignas, not __attribute__, and if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194
--- Comment #3 from joseph at codesourcery dot com ---
GCC already has implicit knowledge of how FE_* for exceptions relate to
the hardware, because it generates calls to __atomic_feraiseexcept, which
is defined in libatomic using FE_* from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94168
--- Comment #3 from joseph at codesourcery dot com ---
The reasoning for rejecting this (for UCNs in both C and C++, for other
characters in C++ because of the C++ rule that such characters get
converted to UCNs) is that the constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 5 Mar 2020, ch3root at openwall dot com wrote:
> What about IBM extended double (double-double)? All cases where (double)(hi +
> lo) != hi are trap representations too?
I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #2 from joseph at codesourcery dot com ---
I think pseudo-denormals should be considered trap representations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #41 from joseph at codesourcery dot com ---
On Wed, 4 Mar 2020, rguenther at suse dot de wrote:
> We're actually careful about the sign of zero here when recording
> requivalences for propagation. I don't see anything prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94010
--- Comment #4 from joseph at codesourcery dot com ---
See bug 59863, with discussion of the requirement for distinct copies of
the array in recursive calls to have distinct addresses. (Thus, this
would definitely not be valid without -fmerge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926
--- Comment #4 from joseph at codesourcery dot com ---
Some level of permissiveness for built-in functions may be historical,
arising from support for pre-C90 headers without prototypes or with
nonstandard types; that level of permissiveness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #20 from joseph at codesourcery dot com ---
Note that for tiny arguments, tan should raise the underflow exception,
whereas cot should not raise underflow, but maybe you're not concerned
about exceptions raised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #26 from joseph at codesourcery dot com ---
I wouldn't be surprised if such a test could be constructed in the absence
of -funsafe-math-optimizations, that does a single conversion of an
out-of-range integer to a floating-point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93883
--- Comment #5 from joseph at codesourcery dot com ---
On Sat, 22 Feb 2020, roland.illig at gmx dot de wrote:
> The diagnostics in the test should be as close to the diagnostics in the main
> code, in order to make it easy to find th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote:
> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93840
--- Comment #1 from joseph at codesourcery dot com ---
The messages should be read from LOCALEDIR as passed to bindtextdomain.
If GCC is calling bindtextdomain from libc with the correct LOCALEDIR
argument, this is not a GCC bug. (If it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93836
--- Comment #1 from joseph at codesourcery dot com ---
It is never valid to use HOST_WIDE_INT_PRINT macros in calls to diagnostic
functions, because the HOST_WIDE_INT_PRINT macros expand to host printf
formats (e.g. "I64" on MinGW ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #26 from joseph at codesourcery dot com ---
Adding the support for C++ would also be a matter for people who care
about this platform that few people do now care about.
I suspect that if you force the back-end insn pattern effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, bugdal at aerifal dot cx wrote:
> I think the underlying issue here is just that -mpc64 (along with -mpc32) is
> just hopelessly broken and should be docu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #24 from joseph at codesourcery dot com ---
On Tue, 11 Feb 2020, ch3root at openwall dot com wrote:
> So, yeah, it seems integers have to be stable. OTOH, now that there is sse and
> there is -fexcess-precision=standard fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #217 from joseph at codesourcery dot com ---
On Fri, 7 Feb 2020, vincent-gcc at vinc17 dot net wrote:
> According to https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_status
> the possible status are UNCONFIRMED, CON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
--- Comment #10 from joseph at codesourcery dot com ---
This has nothing to do with 84717. The present bug is simply invalid; GCC
is acting as specified in the C standard for excess precision. 84717 is
arguably a legitimate issue about lack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #6 from joseph at codesourcery dot com ---
Do you have any reference to a proposal to that effect? The current
wording in N2454 regarding this says "IEC 60559 requires operations with
specified operand and result fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93491
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 29 Jan 2020, pinskia at gcc dot gnu.org wrote:
> Const functions by definition dont trap or throw. So adding const to a
> function that traps makes the testcase undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91629
--- Comment #2 from joseph at codesourcery dot com ---
The observation about GCC_EXEC_PREFIX is correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91075
--- Comment #1 from joseph at codesourcery dot com ---
This would definitely be invalid C (the prior declaration visible in the
inner scope has no linkage, so the inner declaration has external linkage
and "If, within a translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410
--- Comment #2 from joseph at codesourcery dot com ---
On Fri, 24 Jan 2020, pinskia at gcc dot gnu.org wrote:
> I doubt GCC 9 is going to change.
Indeed. The old approach was inconsistent with normal practice, as I said
in com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93393
--- Comment #2 from joseph at codesourcery dot com ---
Inappropriate use of signaling comparisons on powerpc is bug 58684.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
--- Comment #2 from joseph at codesourcery dot com ---
I'd be concerned about trouble when code processing statements tries to
deal with context that doesn't exist outside of functions. Consider a
statement expression containing a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #11 from joseph at codesourcery dot com ---
On Wed, 15 Jan 2020, christophe.monat at st dot com wrote:
> Now that C11 is complete, would it be acceptable to have GCC define
> __STDC_NO_THREADS__ and __STDC_NO_ATOMIC_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92935
--- Comment #2 from joseph at codesourcery dot com ---
The need to drop qualifiers in typeof in some cases with _Atomic results
from the stdatomic.h implementation, where it is necessary to define
temporaries with the corresponding non-atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241
--- Comment #3 from joseph at codesourcery dot com ---
I think this is actually a regression in 4.5 and later relative to 4.4.
It can be demonstrated in older versions using a different test, with
-std=c99 -pedantic-errors.
#include
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241
--- Comment #2 from joseph at codesourcery dot com ---
I think this is a bug. The expression meets all the requirements for
integer constant expressions (the unevaluated part of the expression has
only permitted operands and casts, much like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93160
--- Comment #2 from joseph at codesourcery dot com ---
Yes, I think this should be rejected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 8 Jan 2020, jakub at gcc dot gnu.org wrote:
> I thought it is this Saturday/Sunday.
Yes, I intend to do the conversion this weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93112
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 1 Jan 2020, jakub at gcc dot gnu.org wrote:
> I must say I don't know if it is correct that interpret_float builds constants
> already in the excess precision (so you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
> Is there also a scenario where it would make sense to have multiple format
> attributes for the same format string?
That seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote:
> But does it make sense to do a format check multiple times for one function?
Yes. You could have a function with one format str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
>
> --- Comment #2 from Lewis Hyatt ---
> (In reply to jos...@code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:
> I was about to work on adding support for -finput-charset into diagnostics
> infrastructure (it currently ignores it), however it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
--- Comment #5 from joseph at codesourcery dot com ---
Most architectures use FLT_EVAL_METHOD == 0. It's specific to x87 (and
older m68k) that FLT_EVAL_METHOD == 2 because x87 doesn't support direct
arithmetic on float or double. Lack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
--- Comment #3 from joseph at codesourcery dot com ---
The value of FLT_EVAL_METHOD applies to constants as well as to
operations. That is, when FLT_EVAL_METHOD == 2, 0.1f has the precision of
long double but the semantic type of float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451
--- Comment #13 from joseph at codesourcery dot com ---
On Fri, 6 Dec 2019, vgupta at synopsys dot com wrote:
> However I'm curious that the test uses qNaN. What is the expected behavior for
> sNaN. If you tweak the testcase sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826
--- Comment #4 from joseph at codesourcery dot com ---
TS 18661-3 has been accepted in principle for C2x, but no-one has done the
editing work needed to get it into the (LaTeX) form needed to add as an
Annex to the C standard. Once that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 3 Dec 2019, jason at gcc dot gnu.org wrote:
> Can we please fix this for GCC 10? It's an important compatibility issue, and
> becoming more important. Bumping to P1 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92720
--- Comment #6 from joseph at codesourcery dot com ---
For the documentation of implementation-defined preprocessor behavior (as
required to be documented by a C implementation for anything the C
standard says is implementation-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92671
--- Comment #1 from joseph at codesourcery dot com ---
I don't think this is a confusing case of precedence, i.e. the proposed
change is not an improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
--- Comment #3 from joseph at codesourcery dot com ---
Isn't this the same as bug 70477?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #4 from joseph at codesourcery dot com ---
The design in the target-independent compiler is that the functions that
get called when processing builtins.def notice that the type involved is
error_mark_node (which in turn gets set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #3 from joseph at codesourcery dot com ---
The C front end explicitly tracks VLA size expressions in type names in
casts and ensures they are evaluated at an appropriate point using a
C_MAYBE_CONST_EXPR (which later turns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86160
--- Comment #2 from joseph at codesourcery dot com ---
Generic (for some floating-point formats, and maybe not for 128-bit
formats on 32-bit targets) bit-pattern is* were implemented by Tamar
Christina's patches that had to be reverted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92428
--- Comment #1 from joseph at codesourcery dot com ---
Each enum type is compatible with an integer type, and in GCC that's
unsigned int by default (in the absence of values that don't fit in
unsigned int), so it's valid to declare a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #7 from joseph at codesourcery dot com ---
Yes, pointers to VLA are variably modified (but are OK in function
arguments even for extern functions, as VLAs there get treated as [*]).
So maybe you should use C_TYPE_VARIABLE_SIZE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #5 from joseph at codesourcery dot com ---
grokdeclarator would be one place to put a check (e.g. near where it
already disallows non-nested functions with variably modified types).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92335
--- Comment #2 from joseph at codesourcery dot com ---
On Mon, 4 Nov 2019, rguenth at gcc dot gnu.org wrote:
> The issue is probably some FP constraints that say we cannot elide ret += 0.0,
Yes, with signed 0 you can't elide + 0.0 as -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #4 from joseph at codesourcery dot com ---
It's actually generic to anything using make; make is designed around
strings that get passed to the shell / split on spaces, rather than having
a generic escape mechanism for special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #1 from joseph at codesourcery dot com ---
This would be an interaction between the built-in function having a printf
format attribute and the header having either a gnu_printf or an ms_printf
format attribute (depending on feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176
--- Comment #9 from joseph at codesourcery dot com ---
On Tue, 29 Oct 2019, f.hollerer at gmx dot net wrote:
> This would:
>
> - shorten the output of assert()
> - minimize the image size due to shorter strings
> - make the buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77918
--- Comment #15 from joseph at codesourcery dot com ---
The glibc patch does not need to wait for GCC 10 to be released (we're not
concerned with old development versions of GCC in glibc, __GNUC_PREREQ
(10, 0) can be used for anything fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41526
--- Comment #5 from joseph at codesourcery dot com ---
My previous comment was that the *patch* for that old bug was a
host-dependency, so the bug having been closed as fixed suggests that the
issue may be present in the source tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229
--- Comment #4 from joseph at codesourcery dot com ---
On Sat, 26 Oct 2019, arieltorti14 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229
>
> --- Comment #2 from Ariel Torti ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92229
--- Comment #1 from joseph at codesourcery dot com ---
Built-in functions related to integer overflow should be defined in terms
of the C abstract machine model, not in terms of processor flags.
See recent WG14 discussions around this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92212
--- Comment #1 from joseph at codesourcery dot com ---
See bugs 14030, 26732, 48091, 64526. Not sure how many bugs in this area
are genuinely different - I suspect a single bug could be considered to
cover the whole area of checking arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #1 from joseph at codesourcery dot com ---
There are various existing bug reports for ICEs involving VLAs and nested
functions (e.g. 59711, 60085, 69193, 70418). I don't know which might be
related to this one (and even if some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92083
--- Comment #2 from joseph at codesourcery dot com ---
Note also that glibc does not support being built with a different long
double ABI from the default one. On architectures where more than one
long double format is supported by glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #37 from joseph at codesourcery dot com ---
On Wed, 9 Oct 2019, stsp at users dot sourceforge.net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
>
> --- Comment #36 from Stas Sergeev ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #35 from joseph at codesourcery dot com ---
On Tue, 8 Oct 2019, stsp at users dot sourceforge.net wrote:
> As well as AS, LD and all the rest?
> But that defeats the entire purpose of configure.
> I need it to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #33 from joseph at codesourcery dot com ---
It can be useful to have the fully-prefixed host tools (but you don't need
to, you can also make your build system set all the variables such as CC
and CXX that are needed for the host).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #29 from joseph at codesourcery dot com ---
On Mon, 7 Oct 2019, stsp at users dot sourceforge.net wrote:
> Is there any way to convince the build system that the
> resulting compiler is alien and cannot be used? I think
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #8 from joseph at codesourcery dot com ---
The code snippet you posted looks like exactly what libgcc2.c would
typically do for __floatundidf. Given that, I'd prefer building the
relevant function from libgcc2.c rather than having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #26 from joseph at codesourcery dot com ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> Ah, I am starting to understand.
> So basically you mean something like this:
> --with-sysroot=$prefix/$target --w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #24 from joseph at codesourcery dot com ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
>
> --- Comment #23 from Stas Sergeev ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #22 from joseph at codesourcery dot com ---
On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> - The stage2 compiler is built with --prefix=/usr and
> installed with the DESTDIR set to the build dir. As the
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #6 from joseph at codesourcery dot com ---
Arm only uses soft-fp for Thumb-1; otherwise it uses Arm-specific assembly
code.
A natural fix might be, for these particular functions, in the hard-float
case, to use the libgcc2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #5 from joseph at codesourcery dot com ---
We're talking about the sequence of pp-tokens in the expansion of bar(foo,
addr), which is (foo) (addr), where foo is followed by ), not about the
definition.
Please take any further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #3 from joseph at codesourcery dot com ---
Macro replacement for function-like macros is defined in C17 6.10.3.
Note in paragraph 10 the words "the function-like macro name followed by a
( as the next preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #20 from joseph at codesourcery dot com ---
The only case where the newly built GCC should be overridden is the
Canadian cross case, and while that does use a pre-installed tool from the
PATH, it's best to use "make all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #4 from joseph at codesourcery dot com ---
The libgcc2.c functions for conversions that get used by default on most
architectures should respect the rounding mode if the underlying
single-word-to-floating-point instruction does so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #18 from joseph at codesourcery dot com ---
No, --with-build-time-tools definitely should not override newly built
tools.
For example, in some bootstrap configurations you have to build GCC more
than once. If you're also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91961
--- Comment #2 from joseph at codesourcery dot com ---
There's bug 80005 for expansion of __has_include arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91918
--- Comment #5 from joseph at codesourcery dot com ---
In general this sort of thing is undefined behavior under 7.1.4. It's
valid to give an error in this case (as the types are wrong), but it's
liable to be hard to do so in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #13 from joseph at codesourcery dot com ---
On Wed, 25 Sep 2019, stsp at users dot sourceforge.net wrote:
> Unfortunately I wasn't able to fully understand the
> idea you explain. You mention "sysroot" and "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91899
--- Comment #5 from joseph at codesourcery dot com ---
Note that you can use -fmerge-all-constants to tell the compiler to allow
merging named constant objects (I haven't checked if that helps in this
case, however).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #14 from joseph at codesourcery dot com ---
On Wed, 25 Sep 2019, nsz at gcc dot gnu.org wrote:
> e.g. currently there is now way to tell what _FloatN
> variants gcc understands, even though -fdump-translation-unit
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #11 from joseph at codesourcery dot com ---
Those -isystem paths are the *non-sysroot* kind of paths for headers for a
cross compiler.
There is no support for building a *non-sysroot* cross toolchain when its
libc is installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828
--- Comment #2 from joseph at codesourcery dot com ---
My view is as stated in
<https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01602.html> and
<https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01544.html>:
* Update the minimum to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91815
--- Comment #5 from joseph at codesourcery dot com ---
Either gcc.dg or gcc.c-torture/compile would be fine for this test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91820
--- Comment #5 from joseph at codesourcery dot com ---
This is probably a duplicate of other bugs for cases that are not required
in the standard to be constant expressions but are permitted as additional
implementation-defined kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91815
--- Comment #1 from joseph at codesourcery dot com ---
Yes, that looks like a plausible fix (given testcase added to the
testsuite and regression testing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #17 from joseph at codesourcery dot com ---
On Tue, 17 Sep 2019, lhyatt at gmail dot com wrote:
> In any case, the underlying source of wcwidth() could easily be changed as a
> drop-in replacement so I guess it can also be d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #14 from joseph at codesourcery dot com ---
On Sun, 15 Sep 2019, lhyatt at gmail dot com wrote:
> I feel like the most portable solution is just to use directly the necessary
> code (from glibc or gnulib or from scratch or wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #9 from joseph at codesourcery dot com ---
I should also note the testsuite point I mentioned in the BoF, and related
points about building target libraries, which mean this is more
complicated than just the driver specs change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91709
--- Comment #4 from joseph at codesourcery dot com ---
See the C17 standard, Annex F.4 "Floating to integer conversion":
"Otherwise, if the floating value is infinite or NaN or if the integral
part of the floating value ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91709
--- Comment #2 from joseph at codesourcery dot com ---
If the result of multiplying by 1.5 is outside the range of the integer
type, the version with multiplication is required to raise the FE_INVALID
exception for the out-of-range conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
--- Comment #16 from joseph at codesourcery dot com ---
Could you give the testcase you expect to be diagnosed with this option
with C++ that isn't diagnosed by default?
201 - 300 of 2017 matches
Mail list logo
