https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
--- Comment #9 from joseph at codesourcery dot com ---
On Thu, 7 Apr 2016, manu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529
>
> --- Comment #8 from Manuel López-Ibáñez ---
> (In reply to Axel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65083
--- Comment #6 from joseph at codesourcery dot com ---
It's basically a matter of whether you consider adding a new symbol
version to be appropriate in a backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70733
--- Comment #4 from joseph at codesourcery dot com ---
This bug report is for C++, where bit-field width is explicitly not part
of the type and bit-field types wider than int are not extensions, not for
C, where there is a line of C90 DRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70742
--- Comment #12 from joseph at codesourcery dot com ---
A script that assumes build = host = target is obviously unacceptable.
You can't do any compilations for $target at all when configuring GCC,
only when configuring its runtime libr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #15 from joseph at codesourcery dot com ---
On Sun, 24 Apr 2016, lopresti at gmail dot com wrote:
> That said, this is clearly a real bug in GCC. memcpy has a well-defined
> interface; GCC emits calls violating that int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70917
--- Comment #1 from joseph at codesourcery dot com ---
Cf what I said in <https://gcc.gnu.org/ml/gcc/2015-10/msg00189.html>:
I think we should clearly update the documentation to reflect reality
regarding source file encodin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63944
--- Comment #6 from joseph at codesourcery dot com ---
That's using the extension of allowing compound literals in static
initializers. Given that extension, we should fix such cases as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70951
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 4 May 2016, msebor at gcc dot gnu.org wrote:
> First, as the C example program shows, a type qualifier on a function return
> type does have an effect even in C. The descr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71062
--- Comment #2 from joseph at codesourcery dot com ---
I don't think it's valid to optimize for comparisons, where dereference
doesn't occur, based on restrict; restrict is only about how an object is
accessed (and as lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 13 May 2016, tschwinge at gcc dot gnu.org wrote:
> We could get rid of this heuristic (the property function_glibc_finite_math in
> combination with matching declarations'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18063
--- Comment #8 from joseph at codesourcery dot com ---
I think we should diagnose the definition of the struct (generally, any
construction of a too-large fixed-size type in any context).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71188
--- Comment #2 from joseph at codesourcery dot com ---
Unlike the diagnostics for values that are not constant integers, any
diagnostic for these cases must not be a pedwarn, because converting an
arbitrary integer constant expression with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71325
--- Comment #1 from joseph at codesourcery dot com ---
libintl is part of GNU gettext and local changes in GCC should be avoided
if not needed, report problems there if still applicable to the current
version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #2 from joseph at codesourcery dot com ---
On Wed, 8 Jun 2016, ch3root at openwall dot com wrote:
> - padding in long double is not copied. Probably ok (in the same way as
> padding
> in substructures is not always copied)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #8 from joseph at codesourcery dot com ---
It's not correct to use flag_signaling_nans for a fix.
flag_signaling_nans is only for cases where a bit-pattern for a signaling
NaN is interpreted as a floating-point value. It&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #11 from joseph at codesourcery dot com ---
On Thu, 9 Jun 2016, ch3root at openwall dot com wrote:
> - mere load (e.g. from a volatile var) of a float or double sNaN traps
> on x86-32 when traps are enabled;
It raises an exc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #15 from joseph at codesourcery dot com ---
On Thu, 9 Jun 2016, ch3root at openwall dot com wrote:
> > For *scalar* assignment that would be fine because of TS 18661-1 saying
> > "Whether C assignment (6.5.16) (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #16 from joseph at codesourcery dot com ---
I've now raised the void context issue on the WG14 reflector
<http://www.open-std.org/jtc1/sc22/wg14/14278>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 10 Jun 2016, ch3root at openwall dot com wrote:
> Ok, what about this:
This bug is closed as INVALID. No-one will pay any attention to comments
on a closed bug propos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #26 from joseph at codesourcery dot com ---
On Sat, 11 Jun 2016, ch3root at openwall dot com wrote:
> > C11 does not
> > consider sNaNs, and TS 18661 is explicitly stating otherwise for them.
>
> You are talk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #28 from joseph at codesourcery dot com ---
On Thu, 16 Jun 2016, ch3root at openwall dot com wrote:
> > All these memory model issues would best be raised directly with WG14,
>
> What is the best way to do it?
If y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559
--- Comment #11 from joseph at codesourcery dot com ---
On Fri, 17 Jun 2016, jakub at gcc dot gnu.org wrote:
> The patch is completely untested though (and wonder if we have testcases for
> not raising exceptions when isgreater etc. arg
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=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=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=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=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=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=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=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 #6 from joseph at codesourcery dot com ---
On Wed, 2 Aug 2017, chris.ol...@iti-global.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
>
> --- Comment #4 from chris.ol...@iti-global.com ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:
> If there is a concern that the attribute could be used on declarations in
> existing code that the optimization might break, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81686
--- Comment #3 from joseph at codesourcery dot com ---
The hook is specified to take an input that's in the basic source
character set ($ is also used with it). Maybe LTO should store the
complete mapping for basic source characters i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81801
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 11 Aug 2017, oss at malat dot biz wrote:
> One could solve it by dividing both pointers by the size before the
> subtraction, but that would make the operation more expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #13 from joseph at codesourcery dot com ---
fp-bit != soft-fp. soft-fp always uses bit-fields (with the order
depending on the endianness). It's possible that in some cases you need
to ensure the declared types of the bit-f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #17 from joseph at codesourcery dot com ---
Presumably the bit-field issue is RX defaulting to MS bit-field layout
(rx_is_ms_bitfield_layout suggests making the structure itself packed
should help).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #10 from joseph at codesourcery dot com ---
A correct (for -frounding-math) SSE sequence would (for arguments with
absolute value < 2**52) add and subtract 2**52 for a positive operand,
-2**52 for a negative operand. Then it wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
--- Comment #11 from joseph at codesourcery dot com ---
(That's essentially what the generic C implementation of rint in glibc
does. I make no assertions about whether inlining this long expansion of
rint for SSE, or even the shorter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82051
--- Comment #3 from joseph at codesourcery dot com ---
On Thu, 31 Aug 2017, zwzhangwen.zhang at huawei dot com wrote:
>volatile long long f1;
> printf ("g_121.f1=%x\n",g_121.f1);
In addition to the other points people
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 1 Sep 2017, aaro.koskinen at iki dot fi wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
>
> --- Comment #2 from Aaro Koskinen ---
> (In reply to Eric B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82153
--- Comment #1 from joseph at codesourcery dot com ---
floor rounds towards -inf. Conversion to int rounds towards 0. That is,
it wouldn't be valid to omit the roundsd because results would be
different for integer arguments. That sai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82153
--- Comment #3 from joseph at codesourcery dot com ---
On Fri, 8 Sep 2017, arjan at linux dot intel.com wrote:
> When a conversion is inexact, a truncated result is returned. If a converted
> result is larger than the maximum signed doub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82158
--- Comment #2 from joseph at codesourcery dot com ---
Falling off a noreturn function sounds like it could be another case to
insert __builtin_trap (), as we do in various cases of undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
--- Comment #2 from joseph at codesourcery dot com ---
The documentation explicitly says -Wpedantic includes some warnings about
things outside of ISO C, beyond those that violate syntax rules or
constraints. (Sometimes this only applies in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 12 Sep 2017, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80942
>
> --- Comment #4 from Vincent Lefèvre ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 12 Sep 2017, vsevolod.livinskij at frtk dot ru wrote:
> struct struct_t {
> unsigned int memb : 13;
> };
>
> extern struct_t b;
> printf("%llu\n&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82272
--- Comment #1 from joseph at codesourcery dot com ---
I think they do have to expand to the tokens 0 and 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318
--- Comment #4 from joseph at codesourcery dot com ---
I think the glibc reasoning is: libm functions do not need to behave as if
written in standard C, so in particular F.6 does not apply to them and
they may return values with excess
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=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=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=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=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 #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=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=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=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=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=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=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=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=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=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 #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 #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=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=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=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=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=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=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 #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=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 #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=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=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=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=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=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=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=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=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=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=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=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=78779
--- Comment #3 from joseph at codesourcery dot com ---
The fallthroughs are intentional.
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=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=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=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=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=78964
--- Comment #9 from joseph at codesourcery dot com ---
See bug 44677.
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=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=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=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=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=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=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=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
1001 - 1100 of 2027 matches
Mail list logo
