https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68456
--- Comment #7 from joseph at codesourcery dot com ---
On Tue, 24 Nov 2015, vaalfreja at gmail dot com wrote:
> And why newlib-stdint header is used in this case? I haven't used any
> newlib-related options in configure. These targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68499
--- Comment #2 from joseph at codesourcery dot com ---
Unknown pragmas are diagnosed with -Wunknown-pragmas (part of -Wall).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68456
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 20 Nov 2015, dmitry.polukhin at gmail dot com wrote:
> What is the advantage of using 'long' instead of 'int' for uint32_t on a
> platform where both types can be use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #34 from joseph at codesourcery dot com ---
On Thu, 19 Nov 2015, ch3root at openwall dot com wrote:
> What does the following mean then?
>
> C11, 4p5:
> "A strictly conforming program[...] It [...] shall not exce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412
--- Comment #3 from joseph at codesourcery dot com ---
It's a bug in libgcc2.c for the subset of targets for which this code gets
used (note 64-bit targets will generally be using it for TImode not
DImode) *and* which have hardware exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412
--- Comment #5 from joseph at codesourcery dot com ---
I'm not aware of anyone working on these exceptions / rounding modes
issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 16 Nov 2015, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
>
> --- Comment #3 from Dominique d'Humieres ---
> > Darwin d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68371
--- Comment #1 from joseph at codesourcery dot com ---
Not a bug. GCC does not support imaginary types. Use __builtin_complex
(GCC 4.7 or later) or the CMPLX macros implemented based on it, or assign
to __real__ and __imag__ of a temporary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356
--- Comment #2 from joseph at codesourcery dot com ---
Darwin defaults to -fno-math-errno, and tests for libm functions setting
errno should be disabled there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68334
--- Comment #1 from joseph at codesourcery dot com ---
I don't see any difference between declaring the function noreturn (or
pure, or const, or returning non-aliased memory like malloc, or ...) and
declaring it to have a certain type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
--- Comment #3 from joseph at codesourcery dot com ---
The reason is as stated in comment#1: it's necessary to examine the token
after "if ( 1 ) ;" to see if it's the "else" keyword; if it were "else",
that tok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #30 from joseph at codesourcery dot com ---
On Wed, 11 Nov 2015, ch3root at openwall dot com wrote:
> 4. From the POV of the standard I don't see much difference between VLA
> and ordinary arrays in this question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
--- Comment #1 from joseph at codesourcery dot com ---
This is not a standards conformance bug, on multiple grounds:
* The C standard does not permit you to define your own copies of standard
library functions (that is, functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #20 from joseph at codesourcery dot com ---
Undefined behavior when the type is created (not when an object of that
type is declared or when sizeof is used) seems entirely in accordance with
normal C practice in areas such as stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 5 Nov 2015, mpolacek at gcc dot gnu.org wrote:
> Started with r218985.
That's what I expected, but my analysis says that that change was OK and
the underlying cause is incorrec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #8 from joseph at codesourcery dot com ---
I don't know what DWARF semantics are meant to be, but the language
semantics are definitely that in C array types are always unqualified,
whereas in C++, while the qualifiers still apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #11 from joseph at codesourcery dot com ---
On Wed, 28 Oct 2015, ch3root at openwall dot com wrote:
> --- Comment #10 from Alexander Cherepanov ---
> On 2015-10-27 20:09, joseph at codesourcery dot com wrote:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #14 from joseph at codesourcery dot com ---
On Wed, 28 Oct 2015, ch3root at openwall dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
>
> --- Comment #13 from Alexander Cherepanov ---
> On 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #8 from joseph at codesourcery dot com ---
I think it's undefined at the point where a type exceeds the limit on the
size of an object (half the address space minus one byte), whether or not
sizeof is used or any object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #22 from joseph at codesourcery dot com ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:
> What is missing in the discussion is a cost of support in gcc of objects
> with size > PTRDIFF_MAX. I guess overhead in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999
--- Comment #24 from joseph at codesourcery dot com ---
I suppose that while EXACT_DIV_EXPR on the individual halves of a
subtraction wouldn't be correct, it would also be correct (given any
constant element size) to do the (right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #4 from joseph at codesourcery dot com ---
On Mon, 26 Oct 2015, ch3root at openwall dot com wrote:
> The core issue is an overflow in size computations which is not limited to
> VLA.
> You can as easily get a crash wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #6 from joseph at codesourcery dot com ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:
> > VLA size overflow, however, is undefined behavior at runtime, not compile
> > time, hence a matter for ubsan.
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68107
--- Comment #1 from joseph at codesourcery dot com ---
grokdeclarator seems to check the declared size of an array (when
processing an array declarator) - that is, the size counted in array
elements - and then has a separate check for the size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
--- Comment #2 from joseph at codesourcery dot com ---
This seems like a matter for -fsanitize=undefined as I suggested in
<https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00948.html>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68044
--- Comment #2 from joseph at codesourcery dot com ---
I don't think use of -masm=intel is within the scope of what glibc wants
to support for inline asm in its headers. Rather, GCC should be made to
inline the relevant function if it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68046
--- Comment #2 from joseph at codesourcery dot com ---
I wonder if it would be possible to map -ftrapv to something like
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error
(whatever is most closely equivalent to -ftrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956
--- Comment #3 from joseph at codesourcery dot com ---
The gnu_printf format attribute is specifically supposed to accept %m; you
can use -pedantic to disallow it. Targets can override what the printf
attribute maps to; see config/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956
--- Comment #5 from joseph at codesourcery dot com ---
There has been some discussion recently of adding -Wformat-pedantic (see
bug 67479), which would seem reasonable to me. A syslog format also seems
reasonable (but we already have bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67854
--- Comment #1 from joseph at codesourcery dot com ---
I wonder if this is yet another issue with macros from system headers
(bool being defined in a system header to expand to _Bool) ... maybe we
need a systematic review of diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67815
--- Comment #3 from joseph at codesourcery dot com ---
Note that this should only be applied when the multiplication of the two
constants can be folded to a single constant (thus, not for
-frounding-math - HONOR_SIGN_DEPENDENT_ROUNDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67730
--- Comment #1 from joseph at codesourcery dot com ---
Probably caused by:
r211978 | mpolacek | 2014-06-25 12:43:05 + (Wed, 25 Jun 2014) | 7
lines
PR c/61162
* c-parser.c (c_parser_statement_after_labels): Pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #5 from joseph at codesourcery dot com ---
GMP does, or did, select an ABI at configuration time that may not be the
same as that used by default by the compiler used to build it. For
example, if building on an x86_64 processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
--- Comment #22 from joseph at codesourcery dot com ---
On Fri, 25 Sep 2015, vries at gcc dot gnu.org wrote:
> Standard: "Let D be a declaration of an ordinary identifier that provides a
> means of designating an object P as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661
--- Comment #6 from joseph at codesourcery dot com ---
The warning is bogus. It appears even if separate declarations are used
for the three variables; maybe it's something to do with the printf call?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67705
--- Comment #4 from joseph at codesourcery dot com ---
Regarding multiple levels of restricted pointers, please see my
annotations of the C99 wording at
<https://gcc.gnu.org/ml/gcc-bugs/2005-01/msg03394.html>, in particular as
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661
--- Comment #1 from joseph at codesourcery dot com ---
You'll need to give a full testcase (complete compilable file and options
used to compile it). What you gave isn't a compilable testcase; it gives
"error: variably modified 'y' at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67624
--- Comment #2 from joseph at codesourcery dot com ---
All NaNs should have the top mantissa bit set in the result of the
conversion (i.e. the result of the conversion should always be a quiet
NaN, not a signaling NaN) - setting that bit also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #3 from joseph at codesourcery dot com ---
I advise looking at __FLT_MAX__, __FLT_MIN__, __FLT_DENORM_MIN__ etc. as
predefined by the compiler to see the appropriate values of various
constants.
> Multiplying (float)MIN_NORMALI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #1 from joseph at codesourcery dot com ---
If I understand what you are doing correctly, this is an unnormal
representation (exponent not zero or maximal, explicit MSB of mantissa
zero). Such representations, which cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #14 from joseph at codesourcery dot com ---
That C++ wording doesn't have any obvious bearing on what "it is
permitted" is intended to be an exception to - the general
implementation-defined nature of type punning (whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67479
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 7 Sep 2015, manu at gcc dot gnu.org wrote:
>
> Index: c-format.c
> ===
> --- c-format.c (revision 227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67479
--- Comment #6 from joseph at codesourcery dot com ---
On Mon, 7 Sep 2015, manu at gcc dot gnu.org wrote:
> Perhaps this should be called then -Wformat-undefined and not depend on
> -Wpedantic at all?
But if you're writing code for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 28 Aug 2015, msebor at gcc dot gnu.org wrote:
> My reading was that the implicit declaration is intended to be in effect only
> for the call to the otherwise undeclared fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67386
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 28 Aug 2015, msebor at gcc dot gnu.org wrote:
GCC isn't completely consistent in diagnosing references to undeclared
functions. In the test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
-D generate documentation
The driver needs to know what's an option and what's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67307
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I don't see an obvious reason to disregard limits here, but haven't
checked the history of the code. C99 inline functions must always have an
extern version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #21 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
_cpp_interpret_identifier converts UCNs to UTF-8 which is the canonical
internal form for identifiers - for UTF-8 in identifiers, you just need to
pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #17 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 18 Aug 2015, ejolson at unr dot edu wrote:
As iconv was installed on every GNU/Linux system I've tried, I'm not sure what
is wrong with using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 18 Aug 2015, ejolson at unr dot edu wrote:
which illustrates that g++ does not process trigraphs inside raw string
literals. Admittedly I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 18 Aug 2015, ssaraswati at gmail dot com wrote:
Ok, have a further question though. For the current test case, which has the
following code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #11 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Sorry, glibc iconv (not libiconv) doesn't handle C99. So your patch
would not work on any GNU host in normal configurations of GCC (libiconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
There is no C99 character set in glibc libiconv (after all, it's not a
character set at all). Converting extended characters to UCNs like that
would in any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote:
--- Comment #6 from Sujoy ssaraswati at gmail dot com ---
(In reply to jos...@codesourcery.com from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 13 Aug 2015, ssaraswati at gmail dot com wrote:
With -fno-signaling-nans (which is the default), we need to fix the ccp so
that
the sNaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 13 Aug 2015, mpolacek at gcc dot gnu.org wrote:
So this looks like a dup of PR39985. It seems that, if anything, we should
modify __typeof to drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 11 Aug 2015, breedlove.matt at gmail dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #3 from Matt Breedlove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Bugs in -fsignaling-nans (in this case, that a conversion of a signaling
NaN from float to double is incorrectly folded) should be fixed just like
any other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Well, making libgcc use a host-side target macro again certainly isn't the
right fix. Why is EH_FRAME_SECTION_NAME differently defined when building
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67119
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 4 Aug 2015, songlinhai0543 at gmail dot com wrote:
I am tracking some old bugs. I notice that many bug patches are not available
from the URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
The uses of the *nonnegative* functions should be removed to determine
what semantics are expected for for floating-point arguments.
If the semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
(s/removed/reviewed/)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66963
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
This is by design. __builtin_choose_expr requires an integer constant
expression which must be evaluated before the type of the result can be
known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
--- Comment #11 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 3 Jul 2015, sergei.ivn+bugzilla at gmail dot com wrote:
Some excerpts from the C11 standard:
/-
If the keyword static also appears within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 25 Jun 2015, P at draigBrady dot com wrote:
I'm not understanding completely TBH. Are flexible array members not special?
Should the optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Although diagnosing this probably makes sense, it's not required by the
standard (An implementation may accept other forms of constant
expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104
--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I think the server is using the standard subversion package from RHEL 6,
not a local build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483
--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I have no backport plans for this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I'd say that for any function for which use of this attribute is
appropriate, suppression of the warning should involve a detailed comment
explaining why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
See C11 6.5.2.2#6 regarding when calls to unprototyped functions involve
undefined behavior. Being able to represent the value is only relevant
where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 5 Jun 2015, su at cs dot ucdavis.edu wrote:
Since int and long long are incompatible, thus the test case's behavior is
undefined. Correct?
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231
--- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Any problem seen on 603e is a different issue from this (fixed)
e500-specific issue and should not be discussed in this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I concur that it would be valid to define those typedefs to be extended
integer types withing the special aliasing properties. The first
suggestion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I think this comes under tracking pointer provenance (DR#260) and saying
that certain arithmetic on pointers derived by casts from integers has
undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Ideally the front-end folding of expressions-of-constants might avoid
folding-for-optimization such as this (instead just folding cases where
the evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
--- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 12 May 2015, manu at gcc dot gnu.org wrote:
Working on this, but it isn't a simple matter of adding pedantic.
Joseph, would testing global_dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
See https://gcc.gnu.org/ml/gcc-patches/2010-10/msg00051.html (whenever
an options structure pointer is available, you should use that rather than
global_*).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
The rule certainly has nothing to do with whether the struct types are
defined inside the union definition, or defined outside and then used
inside via a tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
--- Comment #11 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I don't know what process Jakub and Tobias used (a) to identify relevant
files / changes in glibc and (b) to make all the changes to operate on
__float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Fixed in glibc (commit 7d0b2575416aec2717e8665287d0ab77826a0ade). I'd
advise merging to trunk GCC libquadmath all relevant glibc changes since
the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 13 Apr 2015, gcc at robbertkrebbers dot nl wrote:
NB 1: I do not think that DR #260 applies here
Why not? It seems clear enough that optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 13 Apr 2015, burnus at gcc dot gnu.org wrote:
I am not sure about signalling NAN issues, but doesn't it otherwise also apply
to code like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
The issue is that someone needs to go through all the parsing for OpenMP
constructs, and figure out exactly where to add calls to
convert_lvalue_to_rvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
(If I was re-doing that patch again, I will try to overload inform(), because
inform_with_flags is just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #3 from Manuel López-Ibáñez manu at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
(_Generic does make sure to treat its controlling expression as an rvalue,
removing qualifiers including _Atomic as well as ensuring GCC's internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:
This bugzilla really sucks. There is my second comment that I place here gone
to the void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:
(Perhaps gcc interprets _Generic as you say, but even the standard committee
doesn't agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
stdatomic.h uses both __auto_type and __typeof__. In the cases where
__typeof__ is used, (a) const and _Atomic (and maybe volatile) must be
removed and (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
By design, typeof removes qualifiers in certain cases. Currently it only
removes them from atomic types (as needed for use in stdatomic.h), but
arguably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Tue, 17 Mar 2015, jens.gustedt at inria dot fr wrote:
Eliminating qualifiers in expressions is easy for arithmetic types at least,
something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
That C __builtin_signbit should be type-generic is bug 36757.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Or e.g.
_Atomic int i = 5;
int j = sizeof (i + 1);
which is valid code not involving _Generic. And, similarly:
_Atomic int i = 5;
int j = sizeof (i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Indeed, for C bit-field width is considered part of the type, meaning no
promotion for those wider than int (and no way for va_arg to extract the
value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65275
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
The warning here appears to be bogus; the code looks well-defined to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65231
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 27 Feb 2015, pinskia at gcc dot gnu.org wrote:
Someone needs to add the redirect from
http://gcc.gnu.org/gcc-4.8/c99status.html to http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote:
According to the documentation -
https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote:
The size of atomic object does not match with documentation -
https://gcc.gnu.org/wiki/Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote:
Alignment of single _Atomic object match with documentation :
https://gcc.gnu.org/wiki/Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote:
Hi Joseph,
Could you help me with a link to the correct description of atomic ABI,
which
801 - 900 of 2017 matches
Mail list logo
