https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #15 from Alexander Cherepanov ---
(In reply to rguent...@suse.de from comment #14)
> From a language Pov that's the same.
> But memcpy and friends work on any dynamic type so have to copy all bytes.
Sorry, I don't understand. Bug 6187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #13 from Alexander Cherepanov ---
(In reply to rguent...@suse.de from comment #11)
> I think if the user writes a long double store then padding becomes
> undefined so the testcase in comment#1 in PR61872 is technically
> undefined IM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #10 from Alexander Cherepanov ---
The case of assignment+memcpy -- testcases in comment 0, in pr92824 and similar
-- is fixed.
But the case of memset+assignment -- pr93270 and pr61872 (these seem to be
dups) -- is not fixed. Is it su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #18 from Alexander Cherepanov ---
Adding a `memset` makes trunk fail too:
--
#include
#include
struct s {
char c;
int i;
};
__attribute__((noinline,noclo
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Bit-fields of different widths have their own types in gcc. And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #45 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #44)
> (In reply to Alexander Cherepanov from comment #43)
> > GCC on x86-64 uses the binary encoding for the significand.
>
> In general, yes. This includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #43 from Alexander Cherepanov ---
Joseph, Vincent, thanks a lot for the crash course in decimal floating-point.
Indeed, quite interesting types. Findings so far: bug 94035, comment 5, bug
94111, bug 94122.
Let me try to summarize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Alexander Cherepanov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Split from bug 94103, comment 1.
It seems the optimizer sometimes computes the representation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Alexander Cherepanov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #3 from Alexander Cherepanov ---
*** Bug 92824 has been marked as a duplicate of this bug. ***
ity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Cast to double of a decimal floating-point infinity gives z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
--- Comment #1 from Alexander Cherepanov ---
Example with decimal floating-point:
--
#include
#include
int main()
{
_Decimal32 x = 999; // maximum significand
uns
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
It seems the optimizer sometimes computes the representation of variables from
its value instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #5 from Alexander Cherepanov ---
I see. But the problem with decimal floating-point formats remains...
Based on bug 93806, comment 41, here is an example with equal but different
values:
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #3 from Alexander Cherepanov ---
(In reply to jos...@codesourcery.com from comment #2)
> I think pseudo-denormals should be considered trap representations.
Cool!
What about IBM extended double (double-double)? All cases where (doubl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #40 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #35)
> > You seem to say that either Annex F is fully there or not at all but why?
> > -fno-signed-zeros breaks Annex F but only parts of it. Isn't it possibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
--- Comment #1 from Alexander Cherepanov ---
clang bug -- https://bugs.llvm.org/show_bug.cgi?id=45101
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The problem happens when:
- conditional equivalence propagation replaces an expression with a variable or
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #34 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #13)
> > Since C without Annex F allows arbitrarily awful floating point results,
>
> In C without Annex F, division by 0 is undefined behavior (really undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #11 from Alexander Cherepanov ---
(In reply to Martin Sebor from comment #10)
> An array is implicitly converted to a pointer;
Sometimes converted, sometimes -- not.
> it's not an lvalue.
Why not? Take for example p[1] that we d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
--- Comment #9 from Alexander Cherepanov ---
(In reply to Martin Sebor from comment #8)
> In
>
> int i[4];
> int (*p)[4] = &i;
> bar_aux (p[1]);
>
> p[0] points to i and p[1] to (char*)&i + sizeof (i) (which is the same as
> &i[4]).
It s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #24 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #11)
> But what does "internal consistency" mean?
That's a good question. Here we talk about cases (like
-funsafe-math-optimizations) that are not covered by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #16 from Alexander Cherepanov ---
On 21/02/2020 03.40, vincent-gcc at vinc17 dot net wrote:
> Concerning -fno-signed-zeros, your code has undefined behavior since the sign
> of zero is significant in "1 / x == 1 / 0.", i.e. changing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #8 from Alexander Cherepanov ---
A similar problem happens with -fno-signed-zeros -fno-trapping-math. Not sure
if a separate PR should be filed...
--
#include
__at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90248
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #6 from Alexander Cherepanov ---
I agree that every separate optimization here is quite natural. At the same
time, the end result is quite unnatural.
The following is a look at the situation from an outsider POV.
-funsafe-math-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #28 from Alexander Cherepanov ---
The -funsafe-math-optimizations option has a similar problem (on all
processors, I assume) -- I've just filed pr93806 for it. I guess unstable FP
results are essential for this mode but integers compu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #1 from Alexander Cherepanov ---
And instability of integers then easily taints surrounding code:
--
#include
__attribute__((noipa)) // imagine it in a separate TU
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
With -funsafe-math-optimizations, floating-point results are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
Alexander Cherepanov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #23 from Alexander Cherepanov ---
(In reply to Alexander Monakov from comment #10)
> Also note that both the original and the reduced testcase can be tweaked to
> exhibit the surprising transformation even when -fexcess-precision=stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #22 from Alexander Cherepanov ---
(In reply to jos...@codesourcery.com from comment #11)
> Yes, I agree that any particular conversion to integer executed in the
> abstract machine must produce some definite integer value for each
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #1 from Alexander Cherepanov ---
The instability can also taint surrounding code which leads to nonsense:
--
#include
__attribute__((noipa)) // imagine it in a sep
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Spotted by Alexander Monakov in bug 85957, comment 10...
Not sure if -mpc64 is supposed to be compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
--- Comment #21 from Alexander Cherepanov ---
The following variation works with the trunk:
--
#include
__attribute__((noipa)) // imagine it in a separate TU
static int opaque
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681
--- Comment #1 from Alexander Cherepanov ---
And instability of integers then easily taints surrounding code:
--
#include
__attribute__((noipa)) // imagine it in a separate TU
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
x87 floating-point results are effectively unstable due to possible excess
precision. Without -fexcess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93491
--- Comment #2 from Alexander Cherepanov ---
(In reply to Andrew Pinski from comment #1)
> Const functions by definition dont trap or throw.
They don't trap in all cases when they are really called. But this doesn't mean
they must have a sane be
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
In the following example, the call to the function `g` is guarded by the `f(0)`
call and is never evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #12 from Alexander Cherepanov ---
(In reply to rguent...@suse.de from comment #9)
> This example simply shows that we're propagating the equivalence
> y == x - 1 in the way that the controlled x - 1 becomes y (that's
> possibly a QOI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #6 from Alexander Cherepanov ---
(In reply to Alexander Cherepanov from comment #2)
> But my guess is that the C++ rules will not help. The problem is the
> internal inconsistency so everything will blow up independently of any
> exte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #5 from Alexander Cherepanov ---
(In reply to rguent...@suse.de from comment #3)
> But the first use of the undefined value in the comparison makes
> everything wobbly.
So `if (x == y)` is UB. Or `x == y` is already UB?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #4 from Alexander Cherepanov ---
(In reply to Richard Biener from comment #1)
> guess DOM would also happily propagate equivalences
Yeah, this gives a simpler testcase:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #43 from Alexander Cherepanov ---
The following example demonstrates that the instability taints the surrounding
code even if it's in dead code itself. In particular, this shows that even
making comparisons like `&x + 1 == &y` undefin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #2 from Alexander Cherepanov ---
The problem is much more serious. It's not that C has some guarantees about two
values of `y` while gcc doesn't provide them. It's that one part of gcc assumes
there are some guarantees about two value
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Instability is inconsistency, which leads to logical contradictions, which
leads to total chaos. Similar to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #42 from Alexander Cherepanov ---
I've recently stumbled upon a straightforward description (from Hal Finkel, in
https://bugs.llvm.org/show_bug.cgi?id=34548#c77) for the thing that bothered me
in the second part of comment 17. Roughly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #41 from Alexander Cherepanov ---
(In reply to Richard Biener from comment #38)
> (In reply to Alexander Cherepanov from comment #37)
> > On 30/12/2019 10.51, rguenther at suse dot de wrote:
> > >> Obviously, it could be used to fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #40 from Alexander Cherepanov ---
Example with a flexible array member:
--
#include
#include
__attribute__((noipa)) // imagine it in a separate TU
static void *op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #39 from Alexander Cherepanov ---
For diversity, a couple of examples with zero sized objects. Even though they
don't have pointer arithmetic at all they could be classified as being about
past-the-end pointers:-) Please let me know i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93153
Alexander Cherepanov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45734
--- Comment #9 from Alexander Cherepanov ---
DR 1116 is said to be resolved by P0137R1[1]. By looking through it, I don't
see how it covers testcases from this pr where "right" pointer is used (like
the example in comment 0). And it even introduc
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
It seems gcc doesn't account for a possible type change of local variables due
to storage reuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #37 from Alexander Cherepanov ---
On 30/12/2019 10.51, rguenther at suse dot de wrote:
>> Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b`
>> are two different known arrays and `i` is unknown
>
> That's indeed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #30 from Alexander Cherepanov ---
Sure, I've filed pr93105. Thanks for the analysis!
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
gcc seems to wrongly infer provenance of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93010
--- Comment #2 from Alexander Cherepanov ---
But gcc seems to be better than clang in arranging compound literals in memory
so here is a gcc-only testcase with them:
--
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #28 from Alexander Cherepanov ---
I see the same even with pure pointers. I guess RTL doesn't care about such
differences but it means the problem could bite a relatively innocent code.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #35 from Alexander Cherepanov ---
What remains in this pr is the original problem.
1. The best way to demonstrate that there is indeed a bug here is probably to
compare representation of pointers directly:
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #5 from Alexander Cherepanov ---
1. It should be noted that the idea of problems arising from `p == q ? p : q`
is from Chung-Kil Hur via bug 65752, comment 15.
2. clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44374.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #3 from Alexander Cherepanov ---
For completeness, an example with a guessed pointer, based on the testcase from
bug 65752, comment 0, gcc-only (dom2):
--
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #4 from Alexander Cherepanov ---
Could you please provide a bit more specific reference? If you mean various
discussions about C provenance semantics then they are not about these cases.
All examples in pr93051 and in this pr fully re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #60 from Alexander Cherepanov ---
It seems to me that problems with the optimization `p == q ? p : q` -> `q`
(comment 15, comment 38, comment 56 etc.) are not specific to past-the-end
pointers. So I filed a separated bug for it with v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #34 from Alexander Cherepanov ---
It seems to me that problems with the optimization `if (p == q) use p` -> `if
(p == q) use q` (comment 4 etc.) are not specific to past-the-end pointers. So
I filed a separated bug for it with various
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #2 from Alexander Cherepanov ---
Example with a dead malloc (phiopt2):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a separate T
mal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Similar to pr93051.
The optimizer sometimes changes `p == q ? p : q` to `q`. This is wrong when the
actual provenance of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #1 from Alexander Cherepanov ---
Example with a past-the-end pointer (vrp1, similar to but 93051, comment 0 but
this time with PHI):
--
#include
__attribute__((noi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #2 from Alexander Cherepanov ---
Example with a dead malloc (not in tree-opt):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #1 from Alexander Cherepanov ---
Example with a restricted pointer (dom2):
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *o
ity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The optimizer sometimes changes `if (p == q) use p` to `if (p == q) use q` if
it can track the provenance of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93010
--- Comment #1 from Alexander Cherepanov ---
clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44342
There is a second example there, with memcpy/memcmp, but it doesn't trigger the
bug in gcc so not pasting it here. (Generally gcc seems to be m
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
It's known that the value of a pointer to an object becomes indeterminate afte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
--- Comment #4 from Alexander Cherepanov ---
(In reply to Richard Biener from comment #3)
> shows we're constant folding this to
>
> __builtin_printf ("%lf\n",
> 3.36210314311209350626267781732175260259807934484647124011e-4932);
Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92963
--- Comment #2 from Alexander Cherepanov ---
> p cannot be q as they cannot be based on each other based on my reading of
> 6.7.3.1p3.
Perhaps something like that was intended at some point but I don't see it in
the text. Until you start analyzi
ty: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The question: is `p == q ? p : q` "based" on `p` (as in C11, 6.7.3.1p3)?
First, suppose that the a
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
#include
#include
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #16 from Alexander Cherepanov ---
BTW this bug combines nicely with pr71460. Possible effects:
- padding in a long double inside a struct is lost on x86-64;
- sNaN is converted to qNaN in a double inside a struct on x86-32.
Both are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #9 from Alexander Cherepanov ---
> Now as an exercise build a complete testcase for the DSE issue above.
Source code:
--
#include
#include
struct s {
char c;
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Sometimes padding in structs is not copied even with memcpy. AIUI this is
considered a bug in gcc (similar to pr71452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
--- Comment #11 from Alexander Cherepanov ---
When I was converting the original testcase to malloc I started with a
simple assignment with a cast. Clang optimized it as well (and I posted
it to the clang bug) bug gcc didn't. Essentially this e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
--- Comment #8 from Alexander Cherepanov ---
On 2017-10-27 12:41, rguenth at gcc dot gnu.org wrote:
>> And with allocated memory (C; add placement new's for C++):
>>
>> --
>> #in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81028
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
nent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
A testcase is simplified from
https://stackoverflow.com/questions/46592132/is-this-use-of-the-effective-type-rule-strictly-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Only the first letter of 'offsetof' is shown in another color for the following
te
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
int main()
{
struct s {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #19 from Alexander Cherepanov ---
(In reply to jos...@codesourcery.com from comment #3)
> Except within a larger object, I'm not aware of any reason the cases of
> two objects following or not following each other in memory must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71613
--- Comment #5 from Alexander Cherepanov ---
This bug also affects -pedantic-errors, i.e. it's not merely a cosmetic
bug but also a conformance issue. I don't know how -std=c11 can ignore
constraint violations but -pedantic-errors is supposed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71611
--- Comment #2 from Alexander Cherepanov ---
On 06/22/2016 06:08 PM, jakub at gcc dot gnu.org wrote:
> This has nothing to do with enums based on long, but about anonymous enums.
> is what is used for all types that don't have a name.
> Would yo
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Useful warnings seem to be silenced when macros from system headers are used.
For example, in the example below a warning would be useful
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
S
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Only the first token of the offending value is underlined for this warning.
Underlining all the v
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
extern void abort (void);
enum e1 { c1 };
enum e2 { c2 };
__attribute__((noinline,noclone))
int f
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
enum { a } x; // (1)
unsigned x; // (2)
enum { b } x; // (3)
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #27 from Alexander Cherepanov ---
On 06/12/2016 01:09 AM, joseph at codesourcery dot com wrote:
>>> C11 does not
>>> consider sNaNs, and TS 18661 is explicitly stating otherwise for them.
>>
>> You are talking about C11 + TS 18661 whi
1 - 100 of 176 matches
Mail list logo
