https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:
> 1) When attribute unused is specified on a function argument of pointer type
> in
> a declaration of a function, GCC could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
--- Comment #3 from joseph at codesourcery dot com ---
There is no such thing as an array type whose element is incomplete - you
can't construct, or describe, such a type in C at all, and attempts to do
so have undefined behavior in C90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
--- Comment #1 from joseph at codesourcery dot com ---
In C90, arrays of incomplete types are forbidden because incomplete types
are not (before C11) object types. See footnote 17 in subclause 6.1.2.5.
In C99 this becomes a constraint in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81656
--- Comment #1 from joseph at codesourcery dot com ---
To be clear: that requirement is not a constraint, so no diagnostic is
required. Diagnosis may make sense for _Alignas, but I don't think
different choices of __attribute__ ((al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81647
--- Comment #4 from joseph at codesourcery dot com ---
Indeed, it's purely the *internal* LTGT_EXPR and LTGT RTL for which the
semantics are unclear; the semantics of the built-in function are
unambiguous (exception only for signaling NaNs).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81605
--- Comment #2 from joseph at codesourcery dot com ---
In my view, whenever it's meaningful to act on an attribute for a call via
a function pointer (e.g. format, format_arg, const, pure, noreturn, ...),
the attribute should apply to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821
--- Comment #13 from joseph at codesourcery dot com ---
Previous discussions in this bug suggest it was specific to 32-bit
HOST_WIDE_INT. HOST_WIDE_INT is now always 64-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
--- Comment #5 from joseph at codesourcery dot com ---
In C, in C11 mode, type qualifiers are completely ignored on function
return types, including not affecting type compatibility, after my commit:
r236231 | jsm28 | 2016-05-13 21:35:39 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #6 from joseph at codesourcery dot com ---
The design of what's in separate libraries is historical; since it
probably predates shared libraries, the reason isn't obvious (with shared
libraries, before --as-needed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #4 from joseph at codesourcery dot com ---
In the libm case, POSIX has an explicit list of headers whose functions
may require particular libraries to be linked in. libatomic is required
for use of language features without any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #3 from joseph at codesourcery dot com ---
See what I said in
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02605.html> - I think
linking --as-needed -latomic --no-as-needed makes sense by default when
--as-needed is sup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81330
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 5 Jul 2017, msebor at gcc dot gnu.org wrote:
> GCC eliminates redundant calls to strlen() with intervening calls to strcpy
> but
> it misses an opportunity to do the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81310
--- Comment #2 from joseph at codesourcery dot com ---
It's valid on variables (but hidden aliases to variables in shared
libraries don't work properly, and the static linker has special handling
for the case where a shared libra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81156
--- Comment #4 from joseph at codesourcery dot com ---
My notion of __builtin_tgmath is something like
__builtin_tgmath (0, powf, pow, powl, cpowf, cpow, cpowl, a, b)
where the arguments are: an integer constant expression to distinguish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81156
--- Comment #1 from joseph at codesourcery dot com ---
Different OSes (and sometimes different compilers) have different tgmath.h
implementations. Those implementations typically expand calls to tgmath.h
macros to expansions that repeat their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #9 from joseph at codesourcery dot com ---
On Tue, 20 Jun 2017, vincent-gcc at vinc17 dot net wrote:
> > The current proposed wording for DR#467
> > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81120
--- Comment #5 from joseph at codesourcery dot com ---
On Mon, 19 Jun 2017, dave.anglin at bell dot net wrote:
> Is there a gcc option to select between convertFormat and copy? Loads do
There is no such option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #6 from joseph at codesourcery dot com ---
The current proposed wording for DR#467
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_467> changes
"maximum representable finite floating-point number, [ math fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81120
--- Comment #3 from joseph at codesourcery dot com ---
Of course, such a test is fairly meaningless without -fsignaling-nans.
Then, where long double and double have the same format, "Whether C
assignment (6.5.16) (and conversion as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81080
--- Comment #1 from joseph at codesourcery dot com ---
The usual rule applies that large-file defines *must* come before any
direct or indirect system header includes (with glibc if they come late
they simply won't be effective, for some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050
--- Comment #2 from joseph at codesourcery dot com ---
That's not a valid execution character set (unless char is at least 16
bits, which doesn't currently apply to any GCC target). "The basic
character set shall be present and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #4 from joseph at codesourcery dot com ---
Using stack_t instead of struct sigaltstack is correct. However, the type
declaration should be obtained from . Nothing outside of glibc
should ever include headers or define glibc&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #6 from joseph at codesourcery dot com ---
I thought this was fixed only for certain floating-point formats - and
even for those, not globally for all targets (not for binary128 on 32-bit
targets)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
--- Comment #6 from joseph at codesourcery dot com ---
On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
>
> --- Comment #5 from Martin Sebor ---
> I"m not sure I under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756
--- Comment #6 from joseph at codesourcery dot com ---
On Mon, 15 May 2017, nsz at gcc dot gnu.org wrote:
> fabs and fma identifiers are reserved for the implementation and it is valid
> to
> treat them as constant expression in ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756
--- Comment #5 from joseph at codesourcery dot com ---
On Mon, 15 May 2017, vincent-gcc at vinc17 dot net wrote:
> GCC misses a diagnostic when the fabs() or fma() function is used in an
> initializer. For instance, consider:
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
--- Comment #4 from joseph at codesourcery dot com ---
On Sat, 13 May 2017, msebor at gcc dot gnu.org wrote:
> I don't see what purpose rejecting
>
> bool b = "";
>
> serves when
>
> bool b = !!"&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
--- Comment #2 from joseph at codesourcery dot com ---
See <https://www.polyomino.org.uk/computer/c/const-exprs-c99.txt> for my
old syntactic model of constant expressions in C99. I'd consider it
appropriate to handle implicit con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
--- Comment #1 from joseph at codesourcery dot com ---
I think it should be understood implicitly that it's the initializer *as
converted* that must be a constant expression (and, thus, to be an address
constant, must be of pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
--- Comment #1 from joseph at codesourcery dot com ---
On Mon, 8 May 2017, helmut at subdivi dot de wrote:
> False negatives: Debian is about to further multiarch. That involves moving
> libc headers from /usr/include to /usr/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460
--- Comment #4 from joseph at codesourcery dot com ---
FWIW, my build-many-glibcs.py bots for GCC 7 and mainline are run with
"ulimit -v 16777216" to limit the effects of this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 12 Apr 2017, pascal_cuoq at hotmail dot com wrote:
> Since the open-source world divides the C compilation platform described by
> the
> C standard into C compilers (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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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 #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=46676
--- Comment #2 from joseph at codesourcery dot com ---
Full sentences appear now to be used - but all the diagnostic function
calls now use main_args_p ? "diag 1" : "diag 2" as the msgid argument,
which results in only d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79207
--- Comment #2 from joseph at codesourcery dot com ---
It's hardly specific to those arguments. Any case of two or more calls of
(sin or cos) (+/- x + constant) for same x, possibly different constant,
could be converted (given -funsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #26 from joseph at codesourcery dot com ---
As of r244815 I don't see the ICE building glibc. 193 FAILs in gcc.sum,
60 in g++.sum, which is comparable to the results I reported with the LRA
patches. I don't get ICEs f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #7 from joseph at codesourcery dot com ---
On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
> > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same
> > time as enabling usage of TFmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79117
--- Comment #2 from joseph at codesourcery dot com ---
If you use -fexcess-precision=standard, the classification built-in
functions should convert values with excess range and precision to their
semantic types as required by ISO C (see c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729
--- Comment #2 from joseph at codesourcery dot com ---
FWIW, new C floating-point types such as _Float16 and _Float32 are not
promoted in variable arguments either, which has required a few back-end
changes. Complex types such as _Complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79093
--- Comment #1 from joseph at codesourcery dot com ---
We don't seem to have warning_at_n (only inform_n, warning_at_rich_loc_n,
warning_n, error_n) but it could easily be added to handle this properly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970
--- Comment #7 from joseph at codesourcery dot com ---
This change causes a regression testing glibc. glibc uses "gcc -E -x
c-header -", which now results in an error "cannot use '-' as input
filename for a precompil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964
--- Comment #9 from joseph at codesourcery dot com ---
See bug 44677.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754
--- Comment #8 from joseph at codesourcery dot com ---
On Tue, 20 Dec 2016, jakub at gcc dot gnu.org wrote:
> So, where would be the best place to remove the VLA bounds from parameters of
> fn declarations? Some function calle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77767
--- Comment #6 from joseph at codesourcery dot com ---
I think the append_to_statement_list version should be preferred.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #17 from joseph at codesourcery dot com ---
On Tue, 20 Dec 2016, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
>
> --- Comment #16 from Peter Bergner ---
> (In reply to Vlad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516
--- Comment #9 from joseph at codesourcery dot com ---
That LRA patch (on top of the previous patch) allows the glibc build to
complete. Now running gcc/g++/libstdc++ testsuites (I haven't run them
with an unmodified copy of the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78829
--- Comment #1 from joseph at codesourcery dot com ---
Note that some of these (e.g. VLAs) are extensions in C++ as well. And
some include features beyond the standard ones (e.g. _Complex is standard
C99, but the syntax for complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78779
--- Comment #3 from joseph at codesourcery dot com ---
The fallthroughs are intentional.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 8 Dec 2016, msebor at gcc dot gnu.org wrote:
> But what is specifying multiple declarations of the same function with
> different sets of attributes supposed to mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666
--- Comment #4 from joseph at codesourcery dot com ---
Multiple format attributes for the same function, naming different
arguments as a format string, are perfectly valid; they mean the function
uses multiple format strings (each of which has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #9 from joseph at codesourcery dot com ---
Implementation-specific can in practice include cases where the
implementation deviates from the standard (e.g. Windows 3-digit exponents,
though disabling the optimization for floating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #5 from joseph at codesourcery dot com ---
The radix character is not a POSIX extension. See the C11 7.1.1#2: "The
decimal-point character is the character used by functions that convert
floating-point numbers to or from char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78568
--- Comment #5 from joseph at codesourcery dot com ---
c_fully_fold should not be asked to fold the same expression more than
once. When a subexpression is folded during parsing, for whatever reason,
the result should be wrapped in a tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78605
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 29 Nov 2016, msebor at gcc dot gnu.org wrote:
> As an independent issue, since the type of the arguments to the %f directive
> is
> float (not double), the checker s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #14 from joseph at codesourcery dot com ---
On Tue, 29 Nov 2016, bergner at gcc dot gnu.org wrote:
> Using gdb, I see:
>
> (gdb) info registers f1 f2
> f1 27 (raw 0x403b00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78597
--- Comment #1 from joseph at codesourcery dot com ---
If these fail but weren't previously run then it's not a regression, but
an indication of a wrong-code bug in the float128 support for powerpc (for
which testing was previ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 29 Nov 2016, m.ostapenko at samsung dot com wrote:
> /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to
> `__stack_chk_guard'
You get this if glibc a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #7 from joseph at codesourcery dot com ---
What are the actual high and low doubles in the return from powl? The
simplest reason for the reported result here would be that powl returns a
result very slightly less than 27 (which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #12 from joseph at codesourcery dot com ---
Applying also the third patch
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 242751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78458
--- Comment #11 from joseph at codesourcery dot com ---
For e500v2, that patch moves things from a libgcc build failure to a glibc
build failure having built libgcc successfully: many files in glibc fail
to build with errors of the form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
>
> --- Comment #2 from Uroš Bizjak ---
> For 7.0, somebody change
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.
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=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=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=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=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=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=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=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=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=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 #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=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=77832
--- Comment #3 from joseph at codesourcery dot com ---
See bug 66462.
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=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
601 - 700 of 2027 matches
Mail list logo
