https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95139
--- Comment #1 from joseph at codesourcery dot com ---
Code using the GCC diagnostic functions should use %wd instead of
HOST_WIDE_INT_PRINT, both for translation and because HOST_WIDE_INT_PRINT
is a format for the host printf and may not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #14 from joseph at codesourcery dot com ---
I think it's invalid to refer to element (size_t)-1 of an array; that the
actual integer value used has to be within the range of available array
elements.
It's entirely pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95423
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 29 May 2020, pinskia at gcc dot gnu.org wrote:
> Could there be overflows which don't happen originally?
Yes. Say a == INT_MIN, x == -1, b == 0, for example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
--- Comment #3 from joseph at codesourcery dot com ---
This is of course only valid because signed overflow is undefined; it
wouldn't be a valid optimization with -fwrapv (unless x were narrower than
int so no overflow could occur).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #16 from joseph at codesourcery dot com ---
On Wed, 3 Jun 2020, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
>
> --- Comment #15 from Andrew Pinski ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697
--- Comment #2 from joseph at codesourcery dot com ---
See bug 60540, of which this is probably a duplicate, noting the issue
with losing "inexact" exceptions (and "overflow" for some types) and the
reference to bug 57371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722
--- Comment #3 from joseph at codesourcery dot com ---
See bugs 70490 and 84563 regarding atomic_load of const.
The atomic_load generic function takes a pointer-to-const-atomic argument
just like any other library function that takes an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95748
--- Comment #4 from joseph at codesourcery dot com ---
Note that __alignof__ is preferred alignment, whereas C11 _Alignof (which
only applies to types, not declarations) is the alignment required in all
contexts (so they differ for long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95763
--- Comment #3 from joseph at codesourcery dot com ---
FWIW, the Ada front end has some style checking support (I once broke
bootstrap by applying spelling corrections there, where fixing the
spelling in a comment made a line too long). It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96173
--- Comment #5 from joseph at codesourcery dot com ---
I expect there's a speed/space trade-off here. You can use large tables
for the conversions with less computation, or small tables with more
computation (and the BID implementati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96253
--- Comment #1 from joseph at codesourcery dot com ---
DFP is not supported for either AArch32 or AArch64; nor do the respective
ABI documents say what the ABI would be for it (though a GCC patch for the
AArch64 case was submitted in
<ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96371
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 29 Jul 2020, vries at gcc dot gnu.org wrote:
> Anyway, in absence of all this, without fenv.h support there's no way to set
> the rounding mode, meaning that we can ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96371
--- Comment #2 from joseph at codesourcery dot com ---
The target hook float_exceptions_rounding_supported_p can be used to
determine whether support for exceptions and rounding modes is available.
For any architectures with hardware floating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #10 from joseph at codesourcery dot com ---
On Thu, 30 Jul 2020, rsandifo at gcc dot gnu.org wrote:
> IMO process_init_element shouldn't recurse into vector types
> if the initialisation value is also a vector type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96526
--- Comment #1 from joseph at codesourcery dot com ---
You could define __builtin_totalorder functions, but watch out for the
change made to totalorder functions following a TS 18661-1 clarification
request, from floating-point argument types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760
--- Comment #4 from joseph at codesourcery dot com ---
The increment is addition of 1 in type int (after integer promotions),
followed by conversion back to char. Converting an out-of-range integer
value to a narrower signed integer type is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #4 from joseph at codesourcery dot com ---
IEEE 754 does not specify the choice of output NaN. None of the C
bindings to IEEE 754 specify the choice of output NaN. There are various
architecture differences in choice of output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #5 from joseph at codesourcery dot com ---
The way GCC actually behaves is that this constant is unsigned in the
preprocessor but signed outside the preprocessor. I'm not sure that's
exactly intent (though the preproces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #22 from joseph at codesourcery dot com ---
On Fri, 11 Sep 2020, segher at gcc dot gnu.org wrote:
> > #ifndef RS6000_MODES_H
> > #define RS6000_MODES_H 1
> > #define FLOAT_PRECISION_IFmod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #25 from joseph at codesourcery dot com ---
On Mon, 14 Sep 2020, anlauf at gcc dot gnu.org wrote:
> Remember that Fortran needs a correspondence between a storage representation
> (in bytes / bits) and the kind type on the la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088
--- Comment #1 from joseph at codesourcery dot com ---
On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote:
> This happens because the testcase does
> #define x (
> and "x" is used as parameter names in several function pro
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=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=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=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, not that
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 fix
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=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=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 sp
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
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=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 as
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 dec
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 as
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 into a
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=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=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=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; in
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
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'
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
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, and
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
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=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=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 string
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=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=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=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=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=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=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=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=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
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=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=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 unit
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=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=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=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=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, CONFIRM
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=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 documented a
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=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=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&#
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=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=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-
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=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=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #15 from joseph at codesourcery dot com 2013-02-07 01:42:21 UTC ---
I think the most obvious way to handle volatile and unions for C would be
to follow the handling of const (set C_TYPE_FIELDS_VOLATILE in the same
way as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227
--- Comment #8 from joseph at codesourcery dot com 2013-02-07 01:48:56 UTC ---
On Wed, 6 Feb 2013, ubizjak at gmail dot com wrote:
> > The full line is,
> > internal_error ("resolution sub id " HOST_W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335
--- Comment #2 from joseph at codesourcery dot com 2013-02-15 15:47:00 UTC ---
See <http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00841.html>, where I
discuss what I think would be the appropriate checks for supported
alignment (w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397
--- Comment #4 from joseph at codesourcery dot com 2013-02-19 17:10:46 UTC ---
This looks like it's just an issue with the diagnostic text
(binary_op_error being called with the type in which the floating-point
operand is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56397
--- Comment #6 from joseph at codesourcery dot com 2013-02-19 21:51:56 UTC ---
On Tue, 19 Feb 2013, argentinator.gcc.questions at outlook dot com wrote:
> I tried to print the value of fpclassify for a 'subnormal' value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #55 from joseph at codesourcery dot com 2013-02-22 16:10:49 UTC ---
I believe the arguments to memcmp must point to objects with at least the
given number of bytes. (For strcmp, they must point to NUL-terminated
strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188
--- Comment #6 from joseph at codesourcery dot com 2012-08-08 21:43:18 UTC ---
On Wed, 8 Aug 2012, rth at gcc dot gnu.org wrote:
> > N1370 (C11 draft) 6.5.3.4 paragraph 3 says:
> >
> > The _Alignof operator yields the ali
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
--- Comment #2 from joseph at codesourcery dot com 2012-08-29 19:09:55 UTC ---
You do realise that pretty much nothing in the toolchain checks for
overflows in calculating allocation sizes? If you want to fix such
issues more systematically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
--- Comment #4 from joseph at codesourcery dot com 2012-08-29 21:29:12 UTC ---
On Wed, 29 Aug 2012, fw at gcc dot gnu.org wrote:
> > You do realise that pretty much nothing in the toolchain checks for
> > overflows in calculatin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54408
--- Comment #2 from joseph at codesourcery dot com 2012-09-03 15:47:38 UTC ---
Built-in mathematical functions are generally type-generic where they
correspond to type-generic math.h macros (e.g. isgreater, isnan), not
otherwise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47107
--- Comment #3 from joseph at codesourcery dot com 2012-09-21 16:45:16 UTC ---
On Fri, 21 Sep 2012, amylaar at gcc dot gnu.org wrote:
> Is that the expected behaviour, or is config.sub culpable in allowing
> ix86-netware?
ix86-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360
--- Comment #2 from joseph at codesourcery dot com 2012-09-24 00:16:59 UTC ---
On Sun, 23 Sep 2012, pinskia at gcc dot gnu.org wrote:
> This should be a simple of adding a MULTILIB_MATCHES to t-arm-elf .
> Somethin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907
--- Comment #4 from joseph at codesourcery dot com 2012-10-12 15:40:05 UTC ---
I believe this code is well-defined.
There are two objects modified, p and *p. p is modified by the
assignment, and C11 6.5.16#3 says "The side effe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54935
--- Comment #3 from joseph at codesourcery dot com 2012-10-15 14:58:14 UTC ---
On Mon, 15 Oct 2012, rguenth at gcc dot gnu.org wrote:
> We cannot if-convert this because the store to a[i] may trap as it may be
> in .rodata.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55009
--- Comment #1 from joseph at codesourcery dot com 2012-10-21 23:41:28 UTC ---
The C standard requirements that certain source code has certain semantics
(such as, in this case, overflows making something not an integer constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55095
--- Comment #4 from joseph at codesourcery dot com 2012-10-28 17:58:55 UTC ---
The constant folder (fold-const.c:int_const_binop_1) would seem to be the
place where overflow information would most readily be available for this:
as I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55077
--- Comment #2 from joseph at codesourcery dot com 2012-10-28 18:02:07 UTC ---
On Sat, 27 Oct 2012, manu at gcc dot gnu.org wrote:
> // Expressions, such as those that indicate rounding-down, should NOT
> produce
> warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #15 from joseph at codesourcery dot com 2012-11-05 20:49:24 UTC ---
The glibc code is pretty complicated (using glibc's copies of mpn_*
low-level GMP functions for multiple-precision arithmetic) and entangled
with other
--- Comment #3 from joseph at codesourcery dot com 2009-08-18 15:58 ---
Subject: Re: New: openMP include file causes errors when
compiling with standards checking
On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote:
> Due to non-standard code in the supplied openMP hea
--- Comment #6 from joseph at codesourcery dot com 2009-08-18 16:52 ---
Subject: Re: openMP include file causes errors when
compiling with standards checking
On Tue, 18 Aug 2009, ian dot bush at nag dot co dot uk wrote:
> Also Fortran doesn't have the concept of system hea
--- Comment #7 from joseph at codesourcery dot com 2009-08-19 23:58 ---
Subject: Re: 'configure' checks for Ada compiler but
does not build one
On Wed, 19 Aug 2009, jakub at gcc dot gnu dot org wrote:
> obj-c++ isn't built by default either. And in both cases it i
--- Comment #6 from joseph at codesourcery dot com 2009-08-22 16:43 ---
Subject: Re: Windows %I32 format confusion
On Sat, 22 Aug 2009, ktietz at gcc dot gnu dot org wrote:
> This patch can solve this. There are two possible ways to solve this.
> First) Extend format_length_i
--- Comment #8 from joseph at codesourcery dot com 2009-08-24 16:59 ---
Subject: Re: complex folding inexact
On Mon, 24 Aug 2009, ghazi at gcc dot gnu dot org wrote:
> This brings up the question that it's possible for GCC to produce a
> compile-time result (via M
--- Comment #2 from joseph at codesourcery dot com 2009-08-25 14:48 ---
Subject: Re: undefined reference to `typeinfo for __int128'
On Tue, 25 Aug 2009, bangerth at gmail dot com wrote:
> With current mainline, I just get these errors:
>
> g/x> /home/bangerth/bin
--- Comment #2 from joseph at codesourcery dot com 2009-08-25 16:23 ---
Subject: Re: [4.5 Regression] Syntax error: Unterminated
quoted string
On Tue, 25 Aug 2009, rwild at gcc dot gnu dot org wrote:
> AFACIS, the bug is in the test_summary script, it tries to "pa
301 - 400 of 2027 matches
Mail list logo
