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 ta
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 b
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 #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=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 excep
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 ---
> > Dar
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=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=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",
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=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=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 in the
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
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 inc
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 #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=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
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=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 with
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 #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 #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=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 and
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 do
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=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=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 - if
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 the
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 it
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=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
regar
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=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 modif
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 be
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
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
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=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 ---
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 below, it issues a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67307
--- Comment #1 from 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 provided somewh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #1 from 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 an option argument,
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #21 from 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 in straight through unmodified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #19 from 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 looking at the draft st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #17 from 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 the C99 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #9 from 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 -
>
> float sNaN = __b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #11 from 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
is a completely separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #5 from 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 case b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote:
> --- Comment #6 from Sujoy ---
> (In reply to jos...@codesourcery.com from comment #5)
>
> > With -fno-signalin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #19 from 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 all qualifiers. I.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #5 from 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 is converted to qNaN when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #3 from 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 bug. That sentence is simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #4 from 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 ---
> In gcc/default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67172
--- Comment #2 from 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-cppbuiltin.c and when bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67119
--- Comment #1 from 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 in the bug report.
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #2 from joseph at codesourcery dot com ---
(s/removed/reviewed/)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #1 from 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 are "sign bit is 0", N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66963
--- Comment #5 from 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; __builtin_constant_p is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
--- Comment #11 from 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 the [ and ] of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #10 from 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 be restricte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618
--- Comment #2 from 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." - and this expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104
--- Comment #8 from 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 ---
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 ---
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 the particular use o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424
--- Comment #6 from 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.
Such cases have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66424
--- Comment #3 from 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 the case is a mismatch of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62231
--- Comment #15 from 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 ---
I concur that it would be valid to define those typedefs to be extended
integer types withing the special aliasing properties. The first
suggestion of that on the GCC lists that I know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66090
--- Comment #6 from 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 behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
--- Comment #12 from 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 globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127
--- Comment #1 from 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 operands are actually constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037
--- Comment #1 from 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=65757
--- Comment #11 from 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 rather than long d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
--- Comment #9 from 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 merges in 2012, rather than c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #9 from 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 or typedef.
The "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #1 from 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 based on pointer
origins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
--- Comment #5 from 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 the following? At least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #4 from 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 ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466
--- Comment #2 from 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 too much typing).
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
--- Comment #2 from 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 (if an OpenMP construct reads the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #10 from 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 on that interpretation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #9 from 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. Obviously you did see it, sin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #6 from 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
representation of _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #5 from 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) __auto_type would not be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #3 from 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
>
> __typeof__((a)+0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #1 from 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 ), but
arguably it should do so more generally - this would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625
--- Comment #16 from 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 ---
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);
or
_Atomic int i = 5;
int j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
--- Comment #2 from 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 of such a bit-field passed to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65275
--- Comment #2 from 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 ---
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://gcc.gnu.org/c99status.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #3 from joseph at codesourcery dot com ---
It's quite possible there are x86 struct bugs, cf.
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02840.html> and
<https://gcc.gnu.org/ml/gcc-patches/2013-11/msg02862.html>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145
--- Comment #3 from 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 in fact u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147
--- Comment #1 from 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 alignment of atomic
> obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146
--- Comment #1 from 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/GCCMM/Unaligned
801 - 900 of 2027 matches
Mail list logo
