https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
--- Comment #2 from joseph at codesourcery dot com ---
Note that there are also such cases as
static int x;
struct s { int a[sizeof(x)]; } inline *f (void) { return 0; }
where the reference to x is part of the return type (still syntactically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #2 from joseph at codesourcery dot com ---
Yes, I think that (a) a statement expression is not an lvalue and (b) if
it were (or if the code were changed to move the unary '&' inside the
statement expression), the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
--- Comment #4 from joseph at codesourcery dot com ---
Errors for infinite arguments to math.h functions are generally documented
in Annex F; 7.12.1 just says "an implementation may define additional
domain errors, provided that such e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 9 Jan 2019, msebor at gcc dot gnu.org wrote:
> I don't disagree with the conclusion about the validity of this test case but
> there are examples where GCC does treat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774
--- Comment #1 from joseph at codesourcery dot com ---
Although the wording is different in the two cases (and the rule for
return types is newer), I think qualifiers on function parameters should
be considered as not part of the type just as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88822
--- Comment #1 from joseph at codesourcery dot com ---
If an rvalue's type (or, for that matter, an lvalue's type) is observed
with _Generic, the qualifiers should be consistently dropped.
If a type is observed with typeof, qualifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #10 from joseph at codesourcery dot com ---
Use of stfs on a double-precision value without frsp first is worse than
simply using the wrong rounding mode; in the case of overflow it does a
bitwise defined operation which is pretty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
--- Comment #20 from joseph at codesourcery dot com ---
r261797 removed all references to _ANSI_H_ from stddef.h, so this issue
can't be relevant after then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89043
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 24 Jan 2019, msebor at gcc dot gnu.org wrote:
> The CHANGE HISTORY section for stpcpy says the function was first released in
> Issue 1 and derived from Issue 1 of the SVID:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89052
--- Comment #2 from joseph at codesourcery dot com ---
I'd say it's a bug for GCC to need to allocate memory for the trailing
zero-initialized part of such an object at all; it should only need to
allocate memory for the initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
--- Comment #1 from joseph at codesourcery dot com ---
Guessing this might be another issue from pushdecl being called for
compound literals (r259641).
(Technically of course it's true that the jump misses the initialization
of the anon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #8 from joseph at codesourcery dot com ---
The Arm rule is that the EH machinery needs to avoid using VFP (or other
non-core) registers so that the unwinder can save them on-demand only.
See
<http://infocenter.arm.com/help/to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #22 from joseph at codesourcery dot com ---
A large proportion of the glibc libm tests still segfault for
powerpc-linux-gnu soft-float with that patch applied to GCC trunk.
(Although I don't see nextafter tests among those fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 30 Jan 2019, egallager at gcc dot gnu.org wrote:
> So can this be closed then?
A change *in C11 mode* has nothing to do with possible imprecision of the
wording of a diagnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #10 from joseph at codesourcery dot com ---
My interpretation of that footnote is that it's observing that there is no
way within the standard to *create* linkage between different identifiers
- not that it constrains how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89175
--- Comment #3 from joseph at codesourcery dot com ---
See bug 27682.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #20 from joseph at codesourcery dot com ---
I consider it part of the ABI that long long
__attribute__((__aligned__(__alignof__(long long, as in the definition
of max_align_t (and similarly in gnulib's max_align_t defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
--- Comment #12 from joseph at codesourcery dot com ---
On Wed, 11 Apr 2018, jason at gcc dot gnu.org wrote:
> The quoted passage in the documentation now reads
>
> ---
> Some machines never actually require alignment; they allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85361
--- Comment #3 from joseph at codesourcery dot com ---
See the documentation of -std=, regarding base standards.
# The compiler can accept several base standards, such as @samp{c90} or
# @samp{c++98}, and GNU dialects of those standards, such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #39 from joseph at codesourcery dot com ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
> Code which relies upon this feature to implement a C-style approximation to
> inheritance has been fairly common, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518
--- Comment #2 from joseph at codesourcery dot com ---
You still need some of the built-in functions for use with __float128 in
C++ when that has a different format from long double. It's the built-in
functions for types with the same f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #14 from joseph at codesourcery dot com ---
As I said in comment#10, I think the solution is to remove the specs
making -mieee-fp imply -lieee. (Principally the spec in gnu-user.h. I
don't think this should depend on what li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85585
--- Comment #2 from joseph at codesourcery dot com ---
On Tue, 1 May 2018, peter at cordes dot ca wrote:
> The current strings + pointer-table implementation doesn't merge string
> literals where one string is a suffix of anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38960
--- Comment #5 from joseph at codesourcery dot com ---
Since any non-const function can examine floating-point state, I'd expect
significant effects on code generation. (Whether this also applies to
asms depends on the architecture;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
--- Comment #8 from joseph at codesourcery dot com ---
On Sun, 6 May 2018, roland.illig at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
>
> --- Comment #3 from Roland Illig ---
> (In reply to Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85733
--- Comment #1 from joseph at codesourcery dot com ---
Sounds like a regression if this is the case, since bpabi.h in GCC 7 does
include march=armv8-a in BE8_LINK_SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #1 from joseph at codesourcery dot com ---
This is an obviously perverse interpretation of the standard that is
inconsistent with the intent expressed explicitly if non-normatively in
6.7.6.3#18 ("The identifiers x and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85810
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 16 May 2018, cookevillain at yahoo dot com wrote:
> The Standard is supposed to be a formal specification of the language, so if
No, it isn't. It's for humans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85917
--- Comment #1 from joseph at codesourcery dot com ---
The difference between -std=gnu11 and -std=gnu17 is not meant to be
significant, since apart from the __STDC_VERSION__ change C17 is purely a
bug-fix version and so there are no other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921
--- Comment #14 from joseph at codesourcery dot com ---
On Fri, 25 May 2018, gcc at mailinator dot com wrote:
> https://gcc.gnu.org/install/ doesn't say anything about make headers_install.
That's because it's not part of in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85921
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 25 May 2018, msebor at gcc dot gnu.org wrote:
> Beyond that, #defining macros that match known attributes to something else
> seems like asking for trouble. It even came up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #11 from joseph at codesourcery dot com ---
On Mon, 28 May 2018, vincent-gcc at vinc17 dot net wrote:
> floating-point expression: Once a floating-point number has been converted
> into
> an integer type, the value of thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85995
--- Comment #3 from joseph at codesourcery dot com ---
See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make",
"Undefining @code{__STDC__} when @option{-ansi} is not used." (and the
descripti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997
--- Comment #1 from joseph at codesourcery dot com ---
Well, that's a VLA before the decay to pointer type, and thus violates the
C90 constraint referenced in the diagnostic. So a diagnostic is obviously
required with -std=c90 -pedant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85997
--- Comment #3 from joseph at codesourcery dot com ---
The requirements on array declarators apply before parameter arrays decay
to pointers; see DR#047 (which concerns the case of an incomplete element
type - not itself a constraint violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85995
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 1 Jun 2018, vincent-gcc at vinc17 dot net wrote:
> Programmers normally use conditionals on '__STDC__' to ask whether
> it is safe to use certain feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
--- Comment #1 from joseph at codesourcery dot com ---
Yes, this code needs to be fixed to avoid undefined overflow (if argnum >
INT_MAX / 10 || (argnum == INT_MAX / 10 && *fcp - '0' > INT_MAX % 10),
record that overflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #10 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> Joseph, do you agree that the following shouldn't fail the compilation?
>
> > echo 'int main(){}'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85961
--- Comment #6 from joseph at codesourcery dot com ---
On Fri, 15 Jun 2018, rguenth at gcc dot gnu.org wrote:
> So - all process_options () option post-processing should go away and be moved
> to finish_options ()?
I think reducing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221
--- Comment #1 from joseph at codesourcery dot com ---
The C17 specification for function return types says "function returning
the unqualified version of T", not "function returning the unqualified,
non-atomic version of T&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #13 from joseph at codesourcery dot com ---
Well, C90 TC1 adds (to the informative Annex listing undefined behavior)
the case of array subscripts being out of range even if they wouldn't be
simply based on the top-level o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
--- Comment #7 from joseph at codesourcery dot com ---
If you use __builtin_nansf128 (which returns _Float128) but __float128 is
long double, it's possible the implicit conversion from storing the result
of __builtin_nansq in y.value re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 24 Jun 2019, rguenth at gcc dot gnu.org wrote:
> so I guess it differs from -frounding-math also in a way that it doesn't
> guard FENV access of the exception state (I&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90993
--- Comment #2 from joseph at codesourcery dot com ---
Note that this is only valid with -fno-trapping-math (since integer
division is not permitted to raise the "inexact" exception flag). (With
AVX-512 there are instruction var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
--- Comment #12 from joseph at codesourcery dot com ---
On Thu, 1 Aug 2019, ubizjak at gmail dot com wrote:
> It also means that __builtin_islessgreater is confusingly named.
No, __builtin_islessgreater corresponds to the ISO C islessgrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91046
--- Comment #3 from joseph at codesourcery dot com ---
There can't be any debug info issues specific to empty translation units,
given that
_Static_assert (1, "");
is valid as a translation unit in ISO C, and doesn't d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736
--- Comment #11 from joseph at codesourcery dot com ---
Discussions of the change continued into Aug / Sep 2017. In particular,
there were issues with warnings this introduced in the GCC build (of
target libraries), and questions about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #13 from joseph at codesourcery dot com ---
As I noted in bug 40883 comment 8, you can detect such issues in
target-specific code by building a cross compiler using a native compiler
from the same trunk version, and configuring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #32 from joseph at codesourcery dot com ---
I concur that passing CL_DRIVER instead of CL_LANG_ALL is correct here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #3 from joseph at codesourcery dot com ---
There is a known ambiguity in the standard requirements where the argument
has the correct promoted type but not the expected type before promotion.
I wrote up some notes on this some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91226
--- Comment #1 from joseph at codesourcery dot com ---
This appears to be a bug in libdecnumber/bid/bid2dpd_dpd2bid.c.
_bid_to_dpd32 checks for a too-large significand, but _bid_to_dpd64 does
not. Furthermore, _bid_to_dpd128 has the same bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #28 from joseph at codesourcery dot com ---
On Mon, 22 Jul 2019, lhyatt at gmail dot com wrote:
> I am interested in helping out with this if there is still interest to support
> this feature. (Full disclosure, I don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #16 from joseph at codesourcery dot com ---
I think the most likely case for code using such comparisons is not a
mistake, but code doing something like memmove - code that checks whether
two arrays overlap, and which one comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91285
--- Comment #4 from joseph at codesourcery dot com ---
Note that all the standard C pragmas are even more restricted than GCC's
statement-like pragmas - the standard pragmas (which aren't implemented in
GCC) are defined by the C stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88451
--- Comment #6 from joseph at codesourcery dot com ---
I don't think anyone has really been maintaining the fixed-point support
for a very long time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #30 from joseph at codesourcery dot com ---
https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
is the form to complete and send to ass...@gnu.org (to do an assignment
covering past and future
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #18 from joseph at codesourcery dot com ---
I don't expect people to do such comparisons with addresses of local
variables directly. It is plausible that they have a memmove-like
function, and once it gets inlined the compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #5 from joseph at codesourcery dot com ---
It's *accessible objects* whose value on second return from setjmp is the
same as when longjmp is called (unless non-volatile, automatic storage
duration and changed between setjm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
--- Comment #1 from joseph at codesourcery dot com ---
ABI question: is a function that returns a value through such a hidden
pointer required not to write anything to the storage pointed to until it
knows that it will definitely be returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595
--- Comment #3 from joseph at codesourcery dot com ---
The score port was removed in 2014. All open bugs for it should have been
closed at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #8 from joseph at codesourcery dot com ---
A more general representation would facilitate implementing
__builtin_iseqsig (bug 77928).
(As noted in previous discussions, some processors, e.g. MIPS, actually
have a general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91526
--- Comment #7 from joseph at codesourcery dot com ---
There's more or less the same ABI question as in bug 91398 about whether
there is any constraint on the called function writing to the return value
slot in cases where it does not r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
--- Comment #2 from joseph at codesourcery dot com ---
https://gcc.gnu.org/ml/gcc-patches/2009-10/msg01016.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90175
--- Comment #2 from joseph at codesourcery dot com ---
On Wed, 28 Aug 2019, jozefl.gcc at gmail dot com wrote:
> As far as I understand, strings which get passed to warning() or error() or
> other functions with arguments ending in gmsgid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #13 from joseph at codesourcery dot com ---
These functions have to be expanded inline, unconditionally; there are no
library functions they can reliably fall back on in general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #18 from joseph at codesourcery dot com ---
On Wed, 4 Sep 2019, tnfchris at gcc dot gnu.org wrote:
> As far as I am aware, the final version of the patch had no regressions for
> any
> target, including PowerPC which I use
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?
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=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 excee
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=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=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=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=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 of
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=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=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 in
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=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=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=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
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=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
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 #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 al
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 token&
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 fu
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=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=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 #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=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 h
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=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 #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 on
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83397
--- Comment #3 from joseph at codesourcery dot com ---
DR#317 explicitly confirms that () is not a prototype in a function
definition.
It's not valid in ISO C to call a variadic function without a prototype in
scope. To the extent tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396
--- Comment #12 from joseph at codesourcery dot com ---
https://sourceware.org/ml/libc-testresults/2017-q4/msg00460.html
shows GCC build failures on alpha, hppa, ia64, m68k, microblaze, sh,
tilegx, tilepro. (The cases where the GCC build
701 - 800 of 2027 matches
Mail list logo
