--- Comment #5 from joseph at codesourcery dot com 2010-02-09 20:33 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
There may be a few local code changes (Daniel mentioned email handling) to
carry over (it's quite possible newer versions don't need code c
--- Comment #9 from joseph at codesourcery dot com 2010-02-09 21:15 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
I think we agreed some time ago to remove the gccbug script - if we do
that then we shouldn't need to bring over anything related to proce
--- Comment #13 from joseph at codesourcery dot com 2010-02-10 00:20
---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
The main email-related functionality for GCC is: all bugs in the "gcc"
product automatically get CC:ed to gcc-bugs@gcc.gnu.org (maybe o
--- Comment #15 from joseph at codesourcery dot com 2010-02-10 02:29
---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
On Wed, 10 Feb 2010, LpSolit at netscape dot net wrote:
> --- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 ---
> (In
--- Comment #13 from joseph at codesourcery dot com 2010-02-14 02:07
---
Subject: Re: libstdc++ testing does not work remotely
Given the right board file and site.exp, installed libstdc++ testing works
fine for both remote host and remote target (modulo one installed testing
bug
--- Comment #4 from joseph at codesourcery dot com 2010-02-16 12:09 ---
Subject: Re: gfortran: spurious warning of line truncation
at col 72
On Tue, 16 Feb 2010, patrick dot wallace at stfc dot ac dot uk wrote:
> Mystery solved. It is to do with line endings. When gfortran s
--- Comment #1 from joseph at codesourcery dot com 2010-02-16 12:14 ---
Subject: Re: New: Why gcc can't invoke -as
and uses 'as' instead?
The key thing to remember about $prefix/$target/bin
(/usr/m68k-atari-mint/bin in this case) is that it is an *internal*
d
--- Comment #33 from joseph at codesourcery dot com 2010-02-17 17:24
---
Subject: Re: [4.4/4.5 Regression] zlib segfault in
inflate_table() compiled w/ -O -msse2 ftree-vectorize
I believe the ABI *is* that the stack must be 16-byte aligned at function
boundaries, although this is
--- Comment #27 from joseph at codesourcery dot com 2010-02-19 11:13
---
Subject: Re: numeric_limits::is_modulo is
inconsistent with gcc
The issue with -fwrapv not making INT_MIN / -1 and INT_MIN % -1 have
modulo semantics is discussed in bug 30484.
--
http://gcc.gnu.org
--- Comment #12 from joseph at codesourcery dot com 2010-02-21 17:43
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
There is a technical bug here, in that the semantics I intended to
implement and said I was implementing were that implicit conversions
--- Comment #15 from joseph at codesourcery dot com 2010-02-21 18:15
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
> Sorry I do not understand completely your answer. Shouldn't we warn at
--- Comment #17 from joseph at codesourcery dot com 2010-02-21 18:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 -
--- Comment #19 from joseph at codesourcery dot com 2010-02-23 00:29
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Mon, 22 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #18 from manu at gcc dot gnu dot org 2010-02-22 23:56 -
--- Comment #22 from joseph at codesourcery dot com 2010-02-23 16:32
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #20 from manu at gcc dot gnu dot org 2010-02-23 08:39 -
--- Comment #23 from joseph at codesourcery dot com 2010-02-23 16:38
---
Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't
work
On Tue, 23 Feb 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #21 from manu at gcc dot gnu dot org 2010-02-23 10:23 -
--- Comment #6 from joseph at codesourcery dot com 2010-02-25 15:40 ---
Subject: Re: Support -std=c90 as alias for -std=c89
On Thu, 25 Feb 2010, manu at gcc dot gnu dot org wrote:
> Joseph, would you approve a patch for this?
Yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from joseph at codesourcery dot com 2010-03-15 11:18 ---
Subject: Re: ICE with __builtin_isinf() and _Decimal argument
The most recent draft of TR 24732 I have (I don't have the final published
TR) says that all the type-generic classification and comparison m
--- Comment #8 from joseph at codesourcery dot com 2010-03-15 15:17 ---
Subject: Re: [4.3/4.4 Regression] Optimization error on vectors
of uint64_t
On Mon, 15 Mar 2010, rguenth at gcc dot gnu dot org wrote:
> Joseph, is this a valid testcase?
>
> typedef unsigned l
--- Comment #2 from joseph at codesourcery dot com 2010-03-15 21:16 ---
Subject: Re: __extendxftf2 not exported from 32-bit shared
libgcc
Exporting at GCC_4.5.0 is the obvious thing to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43383
--- Comment #7 from joseph at codesourcery dot com 2010-03-18 21:36 ---
Subject: Re: sinl is not computed correctly
On Thu, 18 Mar 2010, bangerth at gmail dot com wrote:
> Also: 1e22 is not exactly representable as a floating point number. By
5**22 is smaller than 2**53, so 1
--- Comment #11 from joseph at codesourcery dot com 2010-03-20 23:46
---
Subject: Re: gcc -O code generation error
I advise referring to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1252.htm
which is what has been integrated in C1X.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from joseph at codesourcery dot com 2010-03-22 12:22 ---
Subject: Re: New: -ffixed-xxx etc processed too early
This has been around for years; when testing my iWMMXt unwind patch
<http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00049.html> I found it
wasn't
--- Comment #1 from joseph at codesourcery dot com 2010-04-01 16:50 ---
Subject: Re: New: Uploading to gnu.org will fail due to
automake security issue
If no-dist works to pass the gnu.org check, that (unlike upgrades) should
be OK for 4.4 and 4.3 branches.
I updated the
--- Comment #2 from joseph at codesourcery dot com 2010-04-02 16:19 ---
Subject: Re: New: No locale support for Kosovo
Note that the existence of a zh_TW language team
http://translationproject.org/team/zh_TW.html
and associated translations for GCC shows that there is no restriction
--- Comment #6 from joseph at codesourcery dot com 2010-04-02 22:54 ---
Subject: Re: FAIL: abi_check sparc
--enable-nls ought not to affect the choice of locale model; it should be
solely about translations of GCC's own messages. (If libstdc++'s messages
were actuall
--- Comment #3 from joseph at codesourcery dot com 2010-04-04 19:12 ---
Subject: Re: Missed optimization with complex long double
On Sun, 4 Apr 2010, svfuerst at gmail dot com wrote:
> Paragraph 2 in G.5.1 defines multiplication of a real floating point
> type by an ima
--- Comment #1 from joseph at codesourcery dot com 2010-04-06 13:07 ---
Subject: Re: New: add warning for duplicate qualifier
Since C99 allows duplicate qualifiers, this warning is deliberately
conditional on pedantic && !flag_isoc99.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from joseph at codesourcery dot com 2010-04-06 14:14 ---
Subject: Re: add warning for duplicate qualifier
It is generally presumed that if a new feature is deliberately added in a
new language version, as with duplicate qualifiers in C99, then it is
useful for it to
--- Comment #6 from joseph at codesourcery dot com 2010-04-15 19:50 ---
Subject: Re: New: Unexpected error message for bad command
line argument
My multilib selection proposal
<http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> envisages the driver
having a better structured
--- Comment #8 from joseph at codesourcery dot com 2010-04-15 20:37 ---
Subject: Re: Unexpected error message for bad command line
argument
On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:
> (In reply to comment #6)
> > Subject: Re: New: Unexpected error messag
--- Comment #10 from joseph at codesourcery dot com 2010-04-15 21:30
---
Subject: Re: Unexpected error message for bad command line
argument
On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #9 from manu at gcc dot gnu dot org 2010-04-15 20:52 ---
&g
--- Comment #12 from joseph at codesourcery dot com 2010-04-15 22:01
---
Subject: Re: Unexpected error message for bad command line
argument
On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:
> I just want to know whether my current approach is feasible or will be
> over
--- Comment #14 from joseph at codesourcery dot com 2010-04-15 22:32
---
Subject: Re: Unexpected error message for bad command line
argument
On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #13 from manu at gcc dot gnu dot org 2010-04-15 22
--- Comment #16 from joseph at codesourcery dot com 2010-04-15 23:00
---
Subject: Re: Unexpected error message for bad command line
argument
On Thu, 15 Apr 2010, manu at gcc dot gnu dot org wrote:
> --- Comment #15 from manu at gcc dot gnu dot org 2010-04-15 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #16 from joseph at codesourcery dot com ---
That C __builtin_signbit should be type-generic is bug 36757.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #1 from joseph at codesourcery dot com ---
By design, typeof removes qualifiers in certain cases. Currently it only
removes them from atomic types (as needed for use in ), but
arguably it should do so more generally - this would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 17 Mar 2015, jens.gustedt at inria dot fr wrote:
> Eliminating qualifiers in expressions is easy for arithmetic types at least,
> something like
>
> __typeof__((a)+0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #5 from joseph at codesourcery dot com ---
stdatomic.h uses both __auto_type and __typeof__. In the cases where
__typeof__ is used, (a) const and _Atomic (and maybe volatile) must be
removed and (b) __auto_type would not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #6 from joseph at codesourcery dot com ---
(_Generic does make sure to treat its controlling expression as an rvalue,
removing qualifiers including _Atomic as well as ensuring GCC's internal
representation of _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #9 from joseph at codesourcery dot com ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:
> This bugzilla really sucks. There is my second comment that I place here gone
> to the void. Obviously you did see it, sin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #10 from joseph at codesourcery dot com ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:
> (Perhaps gcc interprets _Generic as you say, but even the standard committee
> doesn't agree on that interpretation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #2 from joseph at codesourcery dot com ---
The issue is that someone needs to go through all the parsing for OpenMP
constructs, and figure out exactly where to add calls to
convert_lvalue_to_rvalue (if an OpenMP construct reads the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #2 from joseph at codesourcery dot com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> (If I was re-doing that patch again, I will try to overload inform(), because
> inform_with_flags is just too much typing).
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
>
> --- Comment #3 from Manuel López-Ibáñez ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
--- Comment #5 from joseph at codesourcery dot com ---
On Mon, 13 Apr 2015, burnus at gcc dot gnu.org wrote:
> I am not sure about signalling NAN issues, but doesn't it otherwise also apply
> to code like the following? At least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #1 from joseph at codesourcery dot com ---
On Mon, 13 Apr 2015, gcc at robbertkrebbers dot nl wrote:
> NB 1: I do not think that DR #260 applies here
Why not? It seems clear enough that optimizations based on pointer
origins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #9 from joseph at codesourcery dot com ---
The rule certainly has nothing to do with whether the struct types are
defined inside the union definition, or defined outside and then used
inside via a tag or typedef.
The "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
--- Comment #9 from joseph at codesourcery dot com ---
Fixed in glibc (commit 7d0b2575416aec2717e8665287d0ab77826a0ade). I'd
advise merging to trunk GCC libquadmath all relevant glibc changes since
the last merges in 2012, rather than c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
--- Comment #11 from joseph at codesourcery dot com ---
I don't know what process Jakub and Tobias used (a) to identify relevant
files / changes in glibc and (b) to make all the changes to operate on
__float128 rather than long d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037
--- Comment #1 from joseph at codesourcery dot com ---
See <https://gcc.gnu.org/ml/gcc-patches/2010-10/msg00051.html> (whenever
an options structure pointer is available, you should use that rather than
global_*).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127
--- Comment #1 from joseph at codesourcery dot com ---
Ideally the front-end folding of expressions-of-constants might avoid
folding-for-optimization such as this (instead just folding cases where
the evaluated operands are actually constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
--- Comment #12 from joseph at codesourcery dot com ---
On Tue, 12 May 2015, manu at gcc dot gnu.org wrote:
> > Working on this, but it isn't a simple matter of adding "pedantic".
>
> Joseph, would testing globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090
--- Comment #6 from joseph at codesourcery dot com ---
I think this comes under tracking pointer provenance (DR#260) and saying
that certain arithmetic on pointers derived by casts from integers has
undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #13 from joseph at codesourcery dot com ---
I concur that it would be valid to define those typedefs to be extended
integer types withing the special aliasing properties. The first
suggestion of that on the GCC lists that I know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231
--- Comment #15 from joseph at codesourcery dot com ---
Any problem seen on 603e is a different issue from this (fixed)
e500-specific issue and should not be discussed in this bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708
--- Comment #5 from joseph at codesourcery dot com ---
See what I said in <http://gcc.gnu.org/ml/gcc/2013-10/msg00280.html> about
the issues with something type-generic regarding detecting overflow on
types smaller than int.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #3 from joseph at codesourcery dot com ---
You'll find other cases where fused operations make complex multiplication
and division *more* accurate.
There is, I suppose, a case for having a version of complex multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778
--- Comment #1 from joseph at codesourcery dot com ---
Please see the advice to architecture maintainers at
<http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html>.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #21 from joseph at codesourcery dot com ---
The reason for laxity about flexible array member constraints is existing
code violating them, as in the glibc header code quoted in
<http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #25 from joseph at codesourcery dot com ---
On Mon, 13 Jan 2014, jakub at gcc dot gnu.org wrote:
> But the glibc headers case you're mentioning wasn't initializing the flexible
> array members, right? (Or even ini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
--- Comment #1 from joseph at codesourcery dot com ---
On Fri, 17 Jan 2014, sam at gcc dot gnu.org wrote:
> Is there anything in the C standard preventing a const array declared in a
> function from being put in .rodata or are those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #9 from joseph at codesourcery dot com ---
Thanks for the testcase. At this point I think we need Andrew MacLeod or
Torvald Riegel to review it and assess what should happen where to fix
this (both for direct uses of the atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #1 from joseph at codesourcery dot com ---
On Mon, 20 Jan 2014, glisse at gcc dot gnu.org wrote:
> LTO is not really a brand new, experimental and exotic option anymore. I
> believe that by default, on systems that support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 21 Jan 2014, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
>
> --- Comment #2 from Marc Glisse ---
> (In reply to jos...@code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891
--- Comment #4 from joseph at codesourcery dot com ---
On Tue, 21 Jan 2014, jakub at gcc dot gnu.org wrote:
> The outer C_MAYBE_CONST_EXPR comes from:
> #5 0x0059abd4 in note_integer_operands (expr= 0x719d8840>) at ../.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891
--- Comment #8 from joseph at codesourcery dot com ---
I guess that means re-folding is the simplest thing to do (in this
int_operands case where an operand might have a C_MAYBE_CONST_EXPR not at
top level), instead of using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #4 from joseph at codesourcery dot com ---
For C I believe it's valid to jump back into a scope like that. I don't
think it affects reuse of stack space, because the variables in the scope
that was left have no defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
--- Comment #29 from joseph at codesourcery dot com ---
As was discussed a couple of years ago, the glibc maintainers are willing
to work with the libstdc++ maintainers on providing whatever features
libstdc++ headers need in a namespace-clean
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59958
--- Comment #1 from joseph at codesourcery dot com ---
The response to C90 DR#075 said memory from malloc must be suitably
aligned for all types, not just those fitting in space of the given size,
and nothing relevant has changed in the malloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #1 from joseph at codesourcery dot com ---
Seems rather like bug 58416 to me, if I understand it correctly (SFmode
and DFmode x87 floating-point loads wrongly used when the result is used
other than for arithmetic). Should only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #11 from joseph at codesourcery dot com ---
On Thu, 30 Jan 2014, jakub at gcc dot gnu.org wrote:
> I guess the important thing is if it is allowed to raise exceptions on a
> simple
> load and store of a floating point v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044
--- Comment #9 from joseph at codesourcery dot com ---
After sending a patch to gcc-patches, please keep pinging weekly on
gcc-patches with the ObjC maintainers CC:ed, and giving the URL of the
original patch submission, for as long as it takes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044
--- Comment #11 from joseph at codesourcery dot com ---
On Wed, 5 Feb 2014, dpapavas at gmail dot com wrote:
> I see, thanks for the advice. Just a clarification: you mean that I should CC
> the personal email of the two objc maintainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
--- Comment #4 from joseph at codesourcery dot com ---
Is the complex multiplication instruction C99 Annex G-conforming, or could
it only be used for -fcx-limited-range?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
--- Comment #1 from joseph at codesourcery dot com ---
There are no specified accuracy requirements for complex multiplication /
division, even under Annex G (parts of which - imaginary types in
particular - are not implemented in GCC at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote:
> I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm
> but normal C code. The normal C code should b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60263
--- Comment #1 from joseph at codesourcery dot com ---
In <http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01524.html>, Jason said
he'd raised the issue of whether C++11 really should be different from C11
regarding those macros being
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37743
--- Comment #11 from joseph at codesourcery dot com ---
Yes, we could do something like that (but I also think it's time to put
the targets without this type information on the deprecation list and warn
their maintainers that the target su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602
--- Comment #16 from joseph at codesourcery dot com ---
It is *not a bug*, and so should remain closed, and no new bug should be
opened. See the explicit "not the array type" wording already quoted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431
--- Comment #3 from joseph at codesourcery dot com ---
The semantics of the abssi2 insn pattern on the most negative integer are
that it returns the argument unchanged (RTL operations are generally
modulo; the semantics don't depend on wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431
--- Comment #6 from joseph at codesourcery dot com ---
That sounds like another case for adding an target-independent feature.
That is, the target description is accurate here but the
target-independent parts of the compiler could do with new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436
--- Comment #8 from joseph at codesourcery dot com ---
Implicit preincludes should probably be disabled when preprocessing .S
files (though I don't know if that would help with this issue).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60523
--- Comment #6 from joseph at codesourcery dot com ---
Octal literals are also used in macro definitions from system headers, so
care would be needed that a warning doesn't apply to those.
Such a warning should of course not apply to 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #4 from joseph at codesourcery dot com ---
On Sat, 15 Mar 2014, harald at gigawatt dot nl wrote:
> Only if the int is out of float's range. If the int is in float's range, but
> merely cannot be represented exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67479
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 7 Sep 2015, manu at gcc dot gnu.org wrote:
>
> Index: c-format.c
> ===
> --- c-format.c (revision 227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67479
--- Comment #6 from joseph at codesourcery dot com ---
On Mon, 7 Sep 2015, manu at gcc dot gnu.org wrote:
> Perhaps this should be called then -Wformat-undefined and not depend on
> -Wpedantic at all?
But if you're writing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #14 from joseph at codesourcery dot com ---
That C++ wording doesn't have any obvious bearing on what "it is
permitted" is intended to be an exception to - the general
implementation-defined nature of type punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #1 from joseph at codesourcery dot com ---
If I understand what you are doing correctly, this is an unnormal
representation (exponent not zero or maximal, explicit MSB of mantissa
zero). Such representations, which cannot be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #3 from joseph at codesourcery dot com ---
I advise looking at __FLT_MAX__, __FLT_MIN__, __FLT_DENORM_MIN__ etc. as
predefined by the compiler to see the appropriate values of various
constants.
> Multiplying (float)MIN_NORMALI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67624
--- Comment #2 from joseph at codesourcery dot com ---
All NaNs should have the top mantissa bit set in the result of the
conversion (i.e. the result of the conversion should always be a quiet
NaN, not a signaling NaN) - setting that bit also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661
--- Comment #1 from joseph at codesourcery dot com ---
You'll need to give a full testcase (complete compilable file and options
used to compile it). What you gave isn't a compilable testcase; it gives
"error: variably modif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661
--- Comment #6 from joseph at codesourcery dot com ---
The warning is bogus. It appears even if separate declarations are used
for the three variables; maybe it's something to do with the printf call?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67705
--- Comment #4 from joseph at codesourcery dot com ---
Regarding multiple levels of restricted pointers, please see my
annotations of the C99 wording at
<https://gcc.gnu.org/ml/gcc-bugs/2005-01/msg03394.html>, in particular as
regar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
--- Comment #22 from joseph at codesourcery dot com ---
On Fri, 25 Sep 2015, vries at gcc dot gnu.org wrote:
> Standard: "Let D be a declaration of an ordinary identifier that provides a
> means of designating an object P as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #5 from joseph at codesourcery dot com ---
GMP does, or did, select an ABI at configuration time that may not be the
same as that used by default by the compiler used to build it. For
example, if building on an x86_64 processor it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67730
--- Comment #1 from joseph at codesourcery dot com ---
Probably caused by:
r211978 | mpolacek | 2014-06-25 12:43:05 + (Wed, 25 Jun 2014) | 7
lines
PR c/61162
* c-parser.c (c_parser_statement_after_labels): Pass the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67815
--- Comment #3 from joseph at codesourcery dot com ---
Note that this should only be applied when the multiplication of the two
constants can be folded to a single constant (thus, not for
-frounding-math - HONOR_SIGN_DEPENDENT_ROUNDING - if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67854
--- Comment #1 from joseph at codesourcery dot com ---
I wonder if this is yet another issue with macros from system headers
(bool being defined in a system header to expand to _Bool) ... maybe we
need a systematic review of diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956
--- Comment #3 from joseph at codesourcery dot com ---
The gnu_printf format attribute is specifically supposed to accept %m; you
can use -pedantic to disallow it. Targets can override what the printf
attribute maps to; see config/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956
--- Comment #5 from joseph at codesourcery dot com ---
There has been some discussion recently of adding -Wformat-pedantic (see
bug 67479), which would seem reasonable to me. A syslog format also seems
reasonable (but we already have bug
1201 - 1300 of 2027 matches
Mail list logo
