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
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=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-trapping-ma
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
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, under
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 UINT_MAX
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
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=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 shou
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=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=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 selected
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=85182
--- Comment #1 from joseph at codesourcery dot com ---
This is how static assertions are defined in C11, not a bug in GCC: it's a
constraint violation if the constant expression compares equal to 0,
regardless of the context in whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
--- Comment #3 from joseph at codesourcery dot com ---
Unless someone can identify a commit that deliberately fixed the bug *and
added appropriate tests to the testsuite*, I'd strongly advise adding
tests to the testsuite before marking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87593
--- Comment #1 from joseph at codesourcery dot com ---
Supporting format_arg for multiple arguments of a function isn't a mistake
or counter-intuitive at all. A correct declaration of the ngettext
function requires more than one forma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #7 from joseph at codesourcery dot com ---
If CC:ing me on a bug, please always state the specific question on which
you want an opinion; don't CC me simply because I maintain the relevant
part of the compiler (I read gcc-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #9 from joseph at codesourcery dot com ---
I think it would be appropriate for the front end to generate something
for return ; that avoids this warning. I don't know whether
that should be a literal return of error_mark_nod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
--- Comment #1 from joseph at codesourcery dot com ---
Note that you can have a custom malloc function (e.g. xmalloc) that pairs
with standard free, so it should be possible to indicate that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741
--- Comment #5 from joseph at codesourcery dot com ---
Send email issues to postmas...@sourceware.org (not overseers, that's
another mailing list on the same server).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
--- Comment #9 from joseph at codesourcery dot com ---
On Mon, 29 Oct 2018, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
>
> --- Comment #8 from Eric Gallager ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 30 Oct 2018, mte.zych at gmail dot com wrote:
> ../gcc-source/configure --build=x86_64-linux-gnu \
> --host=x86_64-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #10 from joseph at codesourcery dot com ---
I was not attempting to confirm that GCC had a particular bug.
In this case: as I said, no excess precision support is hooked up for
decimal floating point (i.e., whatever the back end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83353
--- Comment #5 from joseph at codesourcery dot com ---
asin(sin(a)) is not safe (or at least not simple) because of arguments
outside [-pi/2, pi/2]. sin(asin(a)) is more appropriate with -ffast-math
because arguments outside [-1,1] are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87879
--- Comment #1 from joseph at codesourcery dot com ---
You'd need dataflow information that's not available at that point in the
front end to know that the initializer is indeed the value of fmt at that
point in the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769
--- Comment #6 from joseph at codesourcery dot com ---
If you want the modern process for building a cross toolchain for a
GNU/Linux (or GNU/Hurd) target, look at how glibc's build-many-glibcs.py
does it. (This is not saying you need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
--- Comment #5 from joseph at codesourcery dot com ---
AT_FDCWD was added in glibc 2.4, released 2006-03-06.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88062
--- Comment #1 from joseph at codesourcery dot com ---
This is not a GCC bug. tgmath.h is provided by glibc, not GCC, and glibc
indeed does not yet include the type-generic macros for functions rounding
to a narrower type (nor does glibc yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684
--- Comment #8 from joseph at codesourcery dot com ---
I see no sign of Segher's patch to fix the bug (as opposed to some XFAILs
pending a fix) having been committed, and a trivial testcase still
generates fcmpu instructions with a com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68235
--- Comment #4 from joseph at codesourcery dot com ---
I'm not aware of any fix for this bug (the only commit shown is a change
to testcase options, not a fix).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #7 from joseph at codesourcery dot com ---
Note there are a few places where it's "cannot",
which the most obvious find/sed might not locate. E.g. in lra-remat.c:
/* Map: insn -> candidate representing it. It i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 19 Nov 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> However, there's another option: C11, 6.4.2.1 General, n.71 suggests
>
> On systems in which linkers cannot a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #12 from joseph at codesourcery dot com ---
Note that such issues are not unique to ctan.
E.g., compiling __builtin_jn (10, 1e10) will produce such a hang.
The difference is that in the ctan case the additional algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #13 from joseph at codesourcery dot com ---
MPFR deals with larger exponent ranges for intermediate computations
itself (MPFR functions generally set the maximum possible exponent range
internally). MPC generally doesn't se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 20 Nov 2018, rguenth at gcc dot gnu.org wrote:
> if (fmt->emin < min_exp)
> min_exp = fmt->emin - fmt->p + 1;
> so somehow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88097
--- Comment #5 from joseph at codesourcery dot com ---
As of glibc 2.28, glibc uses __builtin_bswap* when available on all
architectures.
commit 0d40d0ecba3b1e5b8c3b8da01c708fea3948e193
Author: Joseph Myers
Date: Tue Feb 6 21:55:08 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #22 from joseph at codesourcery dot com ---
On Wed, 21 Nov 2018, rguenther at suse dot de wrote:
> /* Nonzero value, possibly overflowing or underflowing. */
> mpfr_init2 (m, SIGNIFICAND_BITS);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
--- Comment #23 from joseph at codesourcery dot com ---
And, yes, at least one extra bit in emin is needed for that sticky
rounding code to work (because the user's source code may have a decimal
constant that is slightly over half the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88144
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 22 Nov 2018, pinskia at gcc dot gnu.org wrote:
> I think one of the reasons why it has not been removed is there is still code
> out there that uses this syntax.
Including
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88173
--- Comment #4 from joseph at codesourcery dot com ---
An ordered comparison (< <= > >=) with qNaN raises the "invalid"
exception. An equality comparison (== !=) does not, and nor do
__builtin_isless etc.
I don't k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54265
--- Comment #2 from joseph at codesourcery dot com ---
The earlier position is preferred because logically at the closing brace
the type should be fully defined and it should no longer be possible to
change properties of it through attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #9 from joseph at codesourcery dot com ---
I'd suggest reviewing the set of files changed to see if any are generated
files, or their sources (configure.ac, aclocal.m4, etc.), and doing a
regeneration in that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
--- Comment #7 from joseph at codesourcery dot com ---
As discussed, the load instructions should never raise underflow
exceptions, and having traps enabled for the nonstandard denormal operand
exception is clearly outside the scope of what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
--- Comment #10 from joseph at codesourcery dot com ---
On Wed, 28 Nov 2018, rguenth at gcc dot gnu.org wrote:
> Hmm, OTOH the C standard specifies that the store to u.b.b makes it the
> u.b the active member and it makes the old co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
--- Comment #12 from joseph at codesourcery dot com ---
This seems a reasonable enough example for punning to me, given that all
accesses are via the union type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
--- Comment #3 from joseph at codesourcery dot com ---
As of October 2017, glibc has a testcase that having main in a shared
library works - that's a valid use case, which should work with crt1.o.
If it doesn't work for some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #2 from joseph at codesourcery dot com ---
The -Wformat -Wpedantic comment should warn for nonstandard formats - but
would do so for all format functions, not a subset. And while we have
separate printf and gnu_printf arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88270
--- Comment #6 from joseph at codesourcery dot com ---
A format attribute for syslog is bug 15338.
(A fully general system for extensible format checking is hard, as I think
it would be a bad idea for it effectively to turn the internals of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
--- Comment #8 from joseph at codesourcery dot com ---
On Fri, 30 Nov 2018, stephen.kim at oracle dot com wrote:
> The glibc commit that triggered this bug is:
> bfff8b1becd7d01c074177df7196ab327cd8c844
That's the copyright date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88362
--- Comment #4 from joseph at codesourcery dot com ---
It's not very clear to me what an aligned attribute on a reference, or a
check of the alignment of a reference, should mean anyway.
Note that in some places, [[]]-style attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88362
--- Comment #6 from joseph at codesourcery dot com ---
On Wed, 5 Dec 2018, msebor at gcc dot gnu.org wrote:
> so that we get consistent behavior for reference members. __alignof__ should
> return the corresponding alignment. For examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88382
--- Comment #2 from joseph at codesourcery dot com ---
The extension is intentionally supported. Thus, it should be documented.
--- Additional Comments From joseph at codesourcery dot com 2005-09-02
12:41 ---
Subject: Re: Manuals in the Portable Document Format (PDF)
On Fri, 2 Sep 2005, pinskia at gcc dot gnu dot org wrote:
> Anyways ps2pdf would be used to generate them anyways so it does not
> mat
--- Additional Comments From joseph at codesourcery dot com 2005-09-02
16:12 ---
Subject: Re: [4.0/4.1 Regression]
tr1/6_containers/unordered/hashtable/23465.cc execution test times out
On Thu, 1 Sep 2005, pcarlini at suse dot de wrote:
> Hi. Can you have a quick look at what
--- Additional Comments From joseph at codesourcery dot com 2005-09-03
13:33 ---
Subject: Re: New: [Ada] Wrong ICE diagnostic formatting
On Sat, 3 Sep 2005, schwab at suse dot de wrote:
> internal_error_function in ada/misc.c uses plain vfprintf for formatting the
> error m
--- Additional Comments From joseph at codesourcery dot com 2005-09-06
15:42 ---
Subject: Re: [3.4/4.0/4.1 Regression] -pedantic -ffast-math
breaks working code
On Tue, 6 Sep 2005, mmitchel at gcc dot gnu dot org wrote:
> The problem behind both diagnostics fact that the C++ fr
--- Additional Comments From joseph at codesourcery dot com 2005-09-09
15:41 ---
Subject: Re: Statement expressions issues
On Fri, 9 Sep 2005, rguenth at gcc dot gnu dot org wrote:
> No testcase? But I think this is fixed on the mainline and only pending on
> 4.0.
> Se
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
22:53 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, geoffk at gcc dot gnu dot org wrote:
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
>
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
23:37 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, neil at daikokuya dot co dot uk wrote:
> > Yes, "spelling" is meant in terms of the source code chara
--- Additional Comments From joseph at codesourcery dot com 2005-09-20
20:05 ---
Subject: Re: -Wparentheses doesn't catch all assignments used
as truth value
On Mon, 19 Sep 2005, pinskia at gcc dot gnu dot org wrote:
> I could sware this was discussed before in a bug.
Y
--- Additional Comments From joseph at codesourcery dot com 2005-09-22
17:24 ---
Subject: Re: New: Missing "operation on xxx may be undefined"
on obvious undefined code
On Thu, 22 Sep 2005, pinskia at gcc dot gnu dot org wrote:
> Take the following example:
&g
--- Additional Comments From joseph at codesourcery dot com 2005-09-28
21:29 ---
Subject: Re: gcc.dg/20050922-1.c relies in stdint.h
On Wed, 28 Sep 2005, pinskia at gcc dot gnu dot org wrote:
> I could swore there were other testcases which included stdint.h but there is
&g
--- Comment #1 from joseph at codesourcery dot com 2005-10-29 20:09 ---
Subject: Re: New: Complex arithmetic on special cases is
incorrect.
On Sat, 29 Oct 2005, kargl at gcc dot gnu dot org wrote:
> * underflow, sign and efficiency bugs by rewriting I*y as
> * (0.0+I)*(y
--- Comment #3 from joseph at codesourcery dot com 2005-10-29 20:48 ---
Subject: Re: [4.0/4.1 Regression] incompatible internal linkage
declarations in different scopes not diagnosed
On Sat, 29 Oct 2005, pinskia at gcc dot gnu dot org wrote:
> Should this block PR 16620 and PR 16
--- Comment #8 from joseph at codesourcery dot com 2005-10-31 01:16 ---
Subject: Re: [4.0/4.1 Regression] cpp error messages contain
wrong line in C++
On Mon, 31 Oct 2005, mmitchel at gcc dot gnu dot org wrote:
> Overall, the Weinberg/Austern patch to improve compilation speed
--- Comment #16 from joseph at codesourcery dot com 2005-11-04 00:05
---
Subject: Re: [3.4/4.0/4.1 Regression] stringification
BUG
On Thu, 3 Nov 2005, mmitchel at gcc dot gnu dot org wrote:
> Joseph, you're probably the person who best understands the behavior required
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55399
--- Comment #1 from joseph at codesourcery dot com 2012-11-19 22:54:40 UTC ---
This is heavily dependent on the details of system headers - though I did
test it for glibc both with and without stdc-predef.h. You'll need to
debug it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55399
--- Comment #3 from joseph at codesourcery dot com 2012-11-20 00:15:42 UTC ---
Well, you need to start by looking at how it "fails", e.g. segfault,
macros found to be predefined not the same as those predefined when the
PCH w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55399
--- Comment #5 from joseph at codesourcery dot com 2012-11-20 00:44:06 UTC ---
So you need to trace the cause of not using the header. -Winvalid-pch may
help, but ultimately you need to find whether the file is examined at all,
if not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55544
--- Comment #8 from joseph at codesourcery dot com 2012-12-01 20:53:02 UTC ---
On Sat, 1 Dec 2012, joerg.rich...@pdv-fs.de wrote:
> I see no reference to -fexcess-precision=standard in (garbage sink) bug 323,
> do
> you? So IMH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560
--- Comment #3 from joseph at codesourcery dot com 2012-12-02 20:39:23 UTC ---
This would have been glibc bug 3976 which was fixed for cos by:
commit 804360ed837e3347c9cd9738f25345d2587a1242
Author: Joseph Myers
Date: Fri Mar 2 20:51
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55885
--- Comment #5 from joseph at codesourcery dot com 2013-01-07 15:34:34 UTC ---
INT_MIN % -1 and INT_MIN / -1 *should* be made defined by -fwrapv; that's
bug 30484.
Without -fwrapv, C11 made explicit the intent that the modulo oper
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #6 from joseph at codesourcery dot com 2013-01-09 20:57:13 UTC ---
On Wed, 9 Jan 2013, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
>
> --- Comment #5 from Andrew Pinski 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55961
--- Comment #3 from joseph at codesourcery dot com 2013-01-14 16:05:48 UTC ---
We run configure for the build system in a subdirectory, when build !=
host.
# auto-host.h is the file containing items generated by autoconf and is
# the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
--- Comment #6 from joseph at codesourcery dot com 2013-01-23 17:53:16 UTC ---
I think taking the highest array index seen (determining the array bounds
so that none of the initializers for a flexible array will ever be outside
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086
--- Comment #1 from joseph at codesourcery dot com 2013-01-23 20:47:49 UTC ---
Why do you think this is a bug? GCC meets the semantics of that macro
(that char16_t values are UTF-16 encoded), and gnu99 mode enables u""
strings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086
--- Comment #4 from joseph at codesourcery dot com 2013-01-28 03:43:31 UTC ---
For C, char16_t and char32_t are typedefs in (a header provided
by the C library, not by GCC), *not* built-in types, and __STDC_UTF_16__
is a built-in macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939
--- Comment #20 from joseph at codesourcery dot com 2013-01-30 21:11:31 UTC ---
On Tue, 29 Jan 2013, jakub at gcc dot gnu.org wrote:
> Perhaps -fexcess-precision=standard might fix this too (and be less
> expensive).
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #3 from joseph at codesourcery dot com ---
This is where C distinguishes C11 _Alignof (the minimum alignment the type
is guaranteed to have in all contexts, so 4, see min_align_of_type) from
GNU C __alignof (the normal alignment of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
--- Comment #1 from joseph at codesourcery dot com ---
If __NO_FPRS__ is undefined, that means you are compiling for classic hard
float. Which means that the soft-fp code is not needed - if you need to
keep it in libgcc_s.so for binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69611
--- Comment #5 from joseph at codesourcery dot com ---
I think it's OK for stage 4 - the t-hardfp point is that you'd get a
smaller, faster libgcc on FreeBSD that way, by not compiling soft-fp at
all for non-float128 hard float.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69744
--- Comment #4 from joseph at codesourcery dot com ---
The issue would be t-openbsd setting USER_H to avoid using GCC's own
headers - thus requiring fixincludes to be set up to fix OpenBSD's own
headers if they are missin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
--- Comment #4 from joseph at codesourcery dot com ---
I think you should read the discussion starting at
<https://gcc.gnu.org/ml/gcc/2015-09/msg00135.html> and see how your ideas
compare to it, then maybe try to restart that discussi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69988
--- Comment #7 from joseph at codesourcery dot com ---
libgo.so should have been linked with -lc (probably an implicit -lc from
some spec used when linking shared libraries).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 1 Mar 2016, vincent-gcc at vinc17 dot net wrote:
> > ISO C does not allow for arithmetic operations simply not working -
> > producing invalid results - for some types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
--- Comment #4 from joseph at codesourcery dot com ---
On Tue, 1 Mar 2016, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
>
> --- Comment #2 from Vincent Lefèvre ---
> (In reply to Jos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 4 Mar 2016, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
>
> --- Comment #5 from Vincent Lefèvre ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70114
--- Comment #1 from joseph at codesourcery dot com ---
On Mon, 7 Mar 2016, tanzx940228 at hotmail dot com wrote:
> 3.gcc.error.c
> -
> int main() {
> {
> int foo(float arg0, float arg1);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #5 from joseph at codesourcery dot com ---
The issue is that GCC internally handles IBM long double as having a
106-bit mantissa. There is one value that is larger than can be
represented with a 106-bit mantissa, while still being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #11 from joseph at codesourcery dot com ---
On Mon, 14 Mar 2016, rguenth at gcc dot gnu.org wrote:
> but it will end up with libcalls for isinf, isfinite and isnormal for
> IBM extended double. I'm told glibc does the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66382
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 14 Mar 2016, dan.parrot at mail dot com wrote:
> However, I am still unable to get gcc to compile a very simple program
> when passed the -msoft-float option. Here is the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #9 from joseph at codesourcery dot com ---
I should point out that there is a proposed standard way of controlling
various floating-point optimizations, in the form of pragmas in draft TS
18661-5 (current public draft N2004) (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70400
--- Comment #5 from joseph at codesourcery dot com ---
On Thu, 24 Mar 2016, ryao at gentoo dot org wrote:
> How would GCC "reject all programs" without emitting an error? If there is
> some
By emitting a warning. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428
--- Comment #1 from joseph at codesourcery dot com ---
I don't think -fdebug-prefix-map is meant to cover this case; you're meant
to use it with paths in the form in which they appear in debug info, which
means passing such an optio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70436
--- Comment #10 from joseph at codesourcery dot com ---
I'd consider it a bug that the existing -Wparentheses warning for
ambiguous "else" doesn't warn in this case. As with the existing warning,
that warning is only appro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 30 Mar 2016, hongxu.jia at windriver dot com wrote:
> Do you mean the combination of using *"relative path" source to compile*
> and *"absolute path" in -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 30 Mar 2016, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458
>
> --- Comment #3 from Florian Weimer ---
> (In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518
--- Comment #4 from joseph at codesourcery dot com ---
On Sun, 3 Apr 2016, elyk03 at gmail dot com wrote:
> Should #line be processed unconditionally? I know the preprocessor has to
> keep
It should not be processed in skipped blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #16 from joseph at codesourcery dot com ---
On Tue, 5 Apr 2016, amodra at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
>
> --- Comment #14 from Alan Modra ---
> > if (fmt == &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #4 from joseph at codesourcery dot com ---
On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote:
> According to the manual, if an extension is not incompatible with the base
> standard, it should not be disabled:
In general
901 - 1000 of 2027 matches
Mail list logo
