https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #31 from joseph at codesourcery dot com ---
The following targets still appear to be missing this type information in
GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64),
VxWorks, SymbianOS, LynxOS, QNX, TPF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216
--- Comment #2 from joseph at codesourcery dot com ---
Does the scalar_storage_order attribute added in GCC 6 help for at least
some of this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448
--- Comment #33 from joseph at codesourcery dot com ---
I think it's appropriate for this bug to track the missing pieces, whether
directly or through dependencies on a series of bugs for each target OS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79277
--- Comment #1 from joseph at codesourcery dot com ---
Note that for compatibility you don't want to change either __alignof__
(double) (preferred alignment, 8) or _Alignof (double) (required
alignment, 4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 3 Feb 2017, vogt at linux dot vnet.ibm.com wrote:
> void
> foo (void)
> {
> __typeof__((4294967295U)) a;
> __typeof__((long unsigned int)0 + 0) *b = &a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366
--- Comment #5 from joseph at codesourcery dot com ---
Annex F makes it an unspecified value (i.e. each execution that occurs in
the abstract machine has to act as if it produces some definite value
representable in the resulting type, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332
--- Comment #4 from joseph at codesourcery dot com ---
That would be the %e / %n extraction intended for spec strings. In this
case, I think splitting the string constant between the % and the n should
avoid the %n extraction without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #10 from joseph at codesourcery dot com ---
This is arguably the same as or similar to bug 4210 and its duplicates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79528
--- Comment #2 from joseph at codesourcery dot com ---
On Wed, 15 Feb 2017, jakub at gcc dot gnu.org wrote:
> It seems besides conversion from integer to decimal{32,64} also all the
> arithmetics e.g. in real_arithmetics are perfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79602
--- Comment #1 from joseph at codesourcery dot com ---
We only ever download translations from the TP site and use them
unmodified; we don't make any local changes to the translations in GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677
--- Comment #1 from joseph at codesourcery dot com ---
For the theory of how I think this should behave, see
<https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00419.html> (referring back
to <https://gcc.gnu.org/ml/gcc-bugs/2012-04/msg0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79699
--- Comment #2 from joseph at codesourcery dot com ---
The only mpfr_free_cache call I see in GCC is in the Fortran front end.
Without such a call on exit, leaks in MPFR need not be meaningful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79756
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 1 Mar 2017, rguenth at gcc dot gnu.org wrote:
> but note that convert_vector_to_array_for_subscript will return
> VIEW_CONVERT_EXPR (MAYBE_CONST (...)) then. Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 3 Mar 2017, roland.illig at gmx dot de wrote:
> I assume that somewhere there is some list of functions that take translatable
> strings, since xgettext has to decide which of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846
--- Comment #1 from joseph at codesourcery dot com ---
The correct way to print HOST_WIDE_INT is with %wu etc. formats.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79871
--- Comment #1 from joseph at codesourcery dot com ---
%K means to extract a location from a statement, including inlining
context. See tree-pretty-print.c:percent_K_format. As such, the absence
of a space is correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79874
--- Comment #1 from joseph at codesourcery dot com ---
Without reference to whether it is the case for this particular error,
there are some cases where the code structure is:
* Make consistency checks, possibly reporting diagnostics from them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80001
--- Comment #2 from joseph at codesourcery dot com ---
On Sat, 11 Mar 2017, roland.illig at gmx dot de wrote:
> error_at (loop->loc, loop->routine
> ? "routine call uses same OpenACC parallelism a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80006
--- Comment #2 from joseph at codesourcery dot com ---
The premature promotion probably comes from
targetm.calls.promote_prototypes, which currently takes effect in the
front ends (affecting the IR generated for both caller and callee).
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80071
--- Comment #6 from joseph at codesourcery dot com ---
Note that there are two different proposals regarding __LINE__ for
Markham.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2115.htm
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114
--- Comment #7 from joseph at codesourcery dot com ---
"String literals, and compound literals with const-qualified types, need
not designate distinct objects.". (This is different from named
variables, which can't be merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80131
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 21 Mar 2017, segher at gcc dot gnu.org wrote:
> If we have d = a << (b - c); and a << b does not truncate in the
> original mode, write it as d := (a <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80131
--- Comment #5 from joseph at codesourcery dot com ---
And even with unsigned c, a shift by (30 - 0xU) is perfectly valid
in C; that shift count evaluates to 31U. Whereas a shift by 0xU
is not valid C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80208
--- Comment #2 from joseph at codesourcery dot com ---
The patch submission was
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02187.html>. The rationale
there stands, both that as a standard requirement this must be an error or
a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82390
--- Comment #5 from joseph at codesourcery dot com ---
dg-options is absolutely fine in torture directories, as long as the
options specified are not among the -O options that the test should be
looping over. For example, it's fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82429
--- Comment #2 from joseph at codesourcery dot com ---
Strictly, that a program declares stpcpy should be irrelevant if the
declaration is outside system headers, because it could declare and define
it for some other purpose (even if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
--- Comment #2 from joseph at codesourcery dot com ---
In my view, a separate option for this warning rather than
-Wincompatible-pointer-types would be best (as it's much more likely
people will want to disable this warning than that they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714
--- Comment #8 from joseph at codesourcery dot com ---
The algorithm isn't expecting to use FMA; it's just treating
floating-point numbers as approximate real numbers. I'm not sure why
multiplication has TRUNC, but my gues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
--- Comment #6 from joseph at codesourcery dot com ---
glibc does not use this option. ABI checking in glibc works on binaries
via objdump -T. linknamespace tests do use -aux-info to list functions
exported by a header, and would find it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #2 from joseph at codesourcery dot com ---
I think a value of 0 should be correct with -mfpmath=sse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #13 from joseph at codesourcery dot com ---
Strictly, all x86 excess precision cases are indeterminable (semantics of
-1) except for the case where -fexcess-precision=standard is used
(requires front-end support, present for C only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679
--- Comment #5 from joseph at codesourcery dot com ---
Probably in grokdeclarator the test for _Atomic-qualified array types
should check declspecs->atomic_p rather than atomicp. (The check in the
parser in the case of _Atomic (type-name)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #28 from joseph at codesourcery dot com ---
Well, I also think the existing choice is the more natural choice for the
value of __LINE__ in this case (#line is mainly for use by code
generators, which can always count lines and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #1 from joseph at codesourcery dot com ---
If you have correctly configured GCC so that it can find the system
headers at configure time, include-fixed/limits.h should be constructed as
a concatentation of limitx.h, glimits.h and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #3 from joseph at codesourcery dot com ---
That's not the test I'm talking about. The relevant one is
gcc/Makefile.in's LIMITS_H_TEST, run during a build stage rather than a
configure stage, so you need to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #5 from joseph at codesourcery dot com ---
The expectation for bootstrapping such a cross toolchain is that GCC is
configured and built twice. The first build is static-only, C-only,
inhibit-libc, disables lots of libraries such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 25 Oct 2017, keno at juliacomputing dot com wrote:
> First, the build process looking for the headers in /sys-include rather
> than /include where glibc installs them. Leads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #30 from joseph at codesourcery dot com ---
An option to use just the file's basename in __FILE__ is bug 82176. I
think that's a much more reasonable feature than straining the
interpretation of what counts as the line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #32 from joseph at codesourcery dot com ---
The evidence from the DR discussion is that it's the *less* portable
interpretation - that none of the implementations tested behaved as you
suggest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #34 from joseph at codesourcery dot com ---
None of the other preprocessor maintainers have commented on this bug in
the past four years to disagree with my view of the natural identification
of the current line for this __LINE__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78829
--- Comment #4 from joseph at codesourcery dot com ---
_Alignof is alignment requirement (in all contexts), __alignof__ is
preferred alignment (so on 32-bit x86, for long long they are 4 and 8
respectively, because a long long in a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #7 from joseph at codesourcery dot com ---
As far as I understand the general state of DFP support in GCC: the basic
functionality generally works without needing much maintenance, but no-one
is actively fixing DFP bugs or updating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82861
--- Comment #1 from joseph at codesourcery dot com ---
Should already have been fixed by r254277.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272
--- Comment #4 from joseph at codesourcery dot com ---
I should point out that expanding to the tokens 0 and 1 for C does not in
any way prevent warning (it's a perfectly reasonable optional style
warning); you could for example hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 8 Nov 2017, tydeman at tybor dot com wrote:
> /*
> * C standard appears to be unclear on scope of new type defined in
> * offsetof() macro. Some compilers accept; so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82946
--- Comment #2 from joseph at codesourcery dot com ---
On Sat, 11 Nov 2017, msebor at gcc dot gnu.org wrote:
> other string literal) cannot be a valid representation of a pointer. (The
> only
> way for a conforming program to obtai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997
--- Comment #5 from joseph at codesourcery dot com ---
Jakub's patch is
<https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01041.html>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83060
--- Comment #6 from joseph at codesourcery dot com ---
I'd say for C it's valid to reject &a.s[-1] and &a.s[__PTRDIFF_MAX__] in
static initializers, because there is no guarantee that such addresses are
valid values of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #5 from joseph at codesourcery dot com ---
Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
DF) undefined on function entry and return. Thus, a function can never
assume anything about the value of OF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> This code underflows a signed integer, which is undefined behaviour, if I am
> not mistaken. So, this would not be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #16 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
> > It's valid to call a function in another file compiled with another
> > compiler that follows the ABI,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #18 from joseph at codesourcery dot com ---
On Fri, 24 Nov 2017, ubizjak at gmail dot com wrote:
> In the testcase, there is nothing that violates ABI. It all happens in "g"
> that
> passes calculated result to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194
--- Comment #3 from joseph at codesourcery dot com ---
You definitely cannot assume strcmp (s, t) == -strcmp (t, s), only that
the result has the correct sign in each case.
There should be no need to preserve the exact return value (of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186
--- Comment #6 from joseph at codesourcery dot com ---
For C, what is supposed to happen is that every call to groktypename where
there might be side effects from the type name passes a non-null EXPR
argument, and then the caller arranges for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #1 from joseph at codesourcery dot com ---
I'm not aware of a standard requirement not to use plain int for int32_t
(even with unsigned bit-fields), though it may well be useful to make the
signedness explicit. After all, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #3 from joseph at codesourcery dot com ---
FWIW, current glibc already uses signed int for int32_t (via using it for
__int32_t which is used to define int32_t), entirely as an accident
following a header refactoring, but not for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #29 from joseph at codesourcery dot com ---
I don't see the issue building glibc with build-many-glibcs.py any more,
hence it no longer uses -fno-isolate-erroneous-paths-dereference
-fno-isolate-erroneous-paths-attribute f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #31 from joseph at codesourcery dot com ---
On Wed, 6 Dec 2017, glaubitz at physik dot fu-berlin.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
>
> --- Comment #30 from John Paul Adrian Glaubitz fu-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 1 Sep 2016, bernd.edlinger at hotmail dot de wrote:
> + warning_at (location, 0,
> + "?: expression using integer constants in boolean
> co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77453
--- Comment #1 from joseph at codesourcery dot com ---
Most built-in versions of libm functions just optimize them for constant
arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77450
--- Comment #2 from joseph at codesourcery dot com ---
On Fri, 2 Sep 2016, rguenth at gcc dot gnu.org wrote:
> so it looks like COMPOUND_LITERAL_EXPR is an lvalue? Do we need to
Yes. Compound literals are lvalues; they represent anonym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77530
--- Comment #1 from joseph at codesourcery dot com ---
The x86 back end uses TARGET_96_ROUND_53_LONG_DOUBLE only for the case of
32-bit mode on DragonflyBSD and FreeBSD. From what you're saying here, it
needs to do so for NetBSD as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77586
--- Comment #1 from joseph at codesourcery dot com ---
My offer at <https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01829.html> to
provide an untested patch to always enable TFmode support in libgcc on
ia64, if such an untested patch wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #1 from joseph at codesourcery dot com ---
On Mon, 19 Sep 2016, msebor at gcc dot gnu.org wrote:
> While testing my patch for C++ bug 71912 and gathering material for WG14 paper
> N2083 I noticed that GCC isn't completely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #3 from joseph at codesourcery dot com ---
Anything based on whether things are in system headers won't work for
building glibc as the headers don't look like system headers when building
glibc (which uses -Wall -Werror).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60962
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 26 Sep 2016, rguenth at gcc dot gnu.org wrote:
> /* We want to canonicalize to positive real constants. Pretend
> that only negative ones can be easily n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #5 from joseph at codesourcery dot com ---
VLA side effects in function declarations that are not definitions should
be discarded. VLA side effects in function declarations that are
definitions should occur on entry to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77832
--- Comment #3 from joseph at codesourcery dot com ---
See bug 66462.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77970
--- Comment #1 from joseph at codesourcery dot com ---
I think the correct logic would be something like: if the argument is for
a standard typedef, and the format doesn't correspond exactly to that
typedef (or one differing only by sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992
--- Comment #10 from joseph at codesourcery dot com ---
If you care about information in bytes that are not part of a field with
other semantic significance, you should use -Werror=padded to get errors
on structs with padding and use that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78000
--- Comment #1 from joseph at codesourcery dot com ---
As I've said before, we have to stop doing individual ad hoc fixes for
bugs like this; there are too many of them. We have to work out the
general principles for which warnings shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77992
--- Comment #16 from joseph at codesourcery dot com ---
Obviously any fields implicitly inserted like that must be ignored by the
front ends when processing positional initializers - an initializer { 1,
2, 3 } must initialize three explicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
--- Comment #2 from joseph at codesourcery dot com ---
I think this is essentially the same as bug 77970 - making such warnings
smarter about the case of standard typedefs.
Of course an expression resulting from sizeof must be considered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78109
--- Comment #1 from joseph at codesourcery dot com ---
That's what a PIE is: an ET_DYN that can be directly executed. There is
no bug here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78136
--- Comment #2 from joseph at codesourcery dot com ---
This test clearly needs to use a header local to the testsuite rather than
expecting system headers to work with -traditional-cpp (at which point the
existing exclusion of vxworks_kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 1 Nov 2016, txr at alumni dot caltech.edu wrote:
> Five: The answer to the question is clearly No. The example code
> is very much on point to the "one special guaran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #23 from joseph at codesourcery dot com ---
On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote:
> Seven: Given that the question is now under serious debate, IMO
> someone involved with gcc development should ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 16 Nov 2016, pinskia at gcc dot gnu.org wrote:
> Most likely the use of fma.
Which applies with current x86_64 just as it does with powerpc. It should
be possible to reduce s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
--- Comment #7 from joseph at codesourcery dot com ---
I can't reproduce this with recent GCC 6 branch. Possibly a duplicate of
bug 72747?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #2 from joseph at codesourcery dot com ---
It was r242641.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #3 from joseph at codesourcery dot com ---
I still get the same ICE at r242683.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570
--- Comment #3 from joseph at codesourcery dot com ---
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_412.htm gives an
approved change (presumably to appear in C11 TC2) to stop #elif
conditionals from being evaluated when they don't ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60580
--- Comment #2 from joseph at codesourcery dot com ---
I think following what i386 does is reasonable for now.
I'm a bit dubious of the whole Save design - logically it would be cleaner
if the gcc_options structures were saved just b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60809
--- Comment #6 from joseph at codesourcery dot com ---
I see nothing that says anything about the sequencing of side effects in
initialization expressions with respect to the actual initialization
itself, or parts thereof - either to require a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59778
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 14 Apr 2014, danglin at gcc dot gnu.org wrote:
> I tend to think the failure of this test on hppa is mainly a
> testsuite issue. Specifically, the test performs operations th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60843
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 15 Apr 2014, kdevel at vogtner dot de wrote:
> For conversion to a type of width N, the value is reduced modulo 2^N to be
> within range of the type; no signal is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60843
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 30 Apr 2014, kdevel at vogtner dot de wrote:
> The problem is the erroneous wording "reduction modulo 2^N". *Reduction* by
> definition results in the least *nonnega
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #15 from joseph at codesourcery dot com ---
I think that if the order in which the handlers are executed matters,
something is too fragile in those handlers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61276
--- Comment #6 from joseph at codesourcery dot com ---
You could suggest GCC diagnostic issues to
http://www.linuxfoundation.org/programs/core-infrastructure-initiative if
you wish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315
--- Comment #15 from joseph at codesourcery dot com ---
On Wed, 28 May 2014, manu at gcc dot gnu.org wrote:
> Is any company spending money on GCC Fortran development? That would be
> awesome
> if it were true!
It's true for OpenACC support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447
--- Comment #1 from joseph at codesourcery dot com ---
ISO C does not define _Alignof (object), only _Alignof (type).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447
--- Comment #3 from joseph at codesourcery dot com ---
What makes you think _Alignof depends on -std=c11 (other than for
-pedantic diagnostics)?
I don't see any point in requesting alignment of an object, as opposed to
a type, unless you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61449
--- Comment #1 from joseph at codesourcery dot com ---
I don't see what this has to do with statement expressions. Standard ISO
C rules for storage class specifiers are that block-scope declarations for
functions need to use "ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447
--- Comment #7 from joseph at codesourcery dot com ---
I think _Alignof (expr) should, for example, return the larger alignment
chosen with _Alignas in the case of a declaration using _Alignas, rather
than just being based on the type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #1 from joseph at codesourcery dot com ---
Just because two pointers print the same and have the same bit-pattern
doesn't mean they need to compare equal (see the response to DR#260, which
may be presumed to apply to C11 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #3 from joseph at codesourcery dot com ---
Except within a larger object, I'm not aware of any reason the cases of
two objects following or not following each other in memory must be
mutually exclusive. (If the implementatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563
--- Comment #1 from joseph at codesourcery dot com ---
Note that it's only for certain pairs of floating-point and integer type
that the rounding mode doesn't matter. It's true for float and int,
because the precision of float
--- Comment #3 from joseph at codesourcery dot com 2010-02-07 22:58 ---
Subject: Re: Status of using both -m32 and -m64 on the
same command line
On Sun, 7 Feb 2010, pinskia at gcc dot gnu dot org wrote:
> >I think that this behavior should be unified across gcc's suppo
--- Comment #3 from joseph at codesourcery dot com 2010-02-08 20:40 ---
Subject: Re: Missed vectorization on ARM NEON
On Mon, 8 Feb 2010, pinskia at gcc dot gnu dot org wrote:
> > Try adding -mfloat-abi=softfp to make the compiler actually consider using
> > NEON (needed
--- Comment #3 from joseph at codesourcery dot com 2010-02-09 20:18 ---
Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
I think the call for volunteers at
http://gcc.gnu.org/ml/gcc/2008-03/msg00276.html
still applies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
1101 - 1200 of 2027 matches
Mail list logo
