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=94035
--- Comment #1 from Alexander Cherepanov ---
clang bug -- https://bugs.llvm.org/show_bug.cgi?id=45101
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 #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=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:
-
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=94103
--- Comment #1 from Alexander Cherepanov ---
Example with decimal floating-point:
--
#include
#include
int main()
{
_Decimal32 x = 999; // maximum significand
uns
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 #3 from Alexander Cherepanov ---
*** Bug 92824 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Alexander Cherepanov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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=94103
Alexander Cherepanov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=61872
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
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=92486
--- Comment #18 from Alexander Cherepanov ---
Adding a `memset` makes trunk fail too:
--
#include
#include
struct s {
char c;
int i;
};
__attribute__((noinline,noclo
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=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 #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
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=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;
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
: 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
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
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
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
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=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
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=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
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=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
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 #2 from Alexander Cherepanov ---
Example with a dead malloc (phiopt2):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a separate T
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=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=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=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 #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=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=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=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
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=49330
--- Comment #30 from Alexander Cherepanov ---
Sure, I've filed pr93105. Thanks for the analysis!
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
: 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=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
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=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=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 #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 #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
: 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=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
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 #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=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 #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 #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
: 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=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: ---
x87 floating-point results are effectively unstable due to possible excess
precision. Without -fexcess
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
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=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
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=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
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=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=93681
Alexander Cherepanov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=93806
--- Comment #1 from Alexander Cherepanov ---
And instability of integers then easily taints surrounding code:
--
#include
__attribute__((noipa)) // imagine it in a separate TU
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 #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=90248
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
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=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 #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=93848
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
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
--- 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=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
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The program:
#include
#include
int main()
{
void *p = malloc(10);
int *pi = p;
double *pd = p;
*pi = 1;
printf("*pi = %d\n", *pi);
int a = *pi;
*pd = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #2 from Alexander Cherepanov ---
[CC'ing Martin Sebor and Joseph S. Myers as it's potentially related to
bug 65892.]
On 2016-02-12 01:20, pinskia at gcc dot gnu.org wrote:
>> The last value is wrong, it should be 1.
>
> Why do you t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #8 from Alexander Cherepanov ---
--- Comment #4 from Richard Biener ---
> Actually the middle-end memory model makes this valid and FREs redundant store
> elimination breaks it.
And function boundaries are not an obstacle for validi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #12 from Alexander Cherepanov ---
Seems to be fixed, thanks! I've tried several variations, ok too.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Type-punning is underspecified in the C standard and unions with arrays as
members push it to the limit but the following example seems to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70166
--- Comment #2 from Alexander Cherepanov ---
On 03/11/2016 12:16 PM, rguenth at gcc dot gnu.org wrote:
> You are not accessing through the union type but through a pointer to double
> and int because u.a and p->d decay to a pointer:
>
>*(int
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The function:
int f(int *pi, long *pl)
{
*pi = 1; // (1)
*pl = 0; // (2)
return *(char *)pi; // (3)
}
is optimized (with
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Compiling the program:
int main()
{
int a[1][(0, 1)];
int i = 0;
sizeof a[i++];
}
gives such warnings:
$ gcc -Wall example.c
example.c: In function ‘main’:
example.c:3:14
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
When compiling this program:
int main()
{
struct { int x:2; } s;
12345; &s.x;
}
I get the following error m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70484
--- Comment #7 from Alexander Cherepanov ---
On 04/04/2016 12:37 PM, rguenth at gcc dot gnu.org wrote:
> Fixed on trunk sofar.
Thanks. I've checked some variations of the original testcase --
everything works fine now.
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
When compiling this program:
/--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671
--- Comment #5 from Alexander Cherepanov ---
Thanks. While testing the fix, found somewhat similar problem with
offsetof -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730 .
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70746
Alexander Cherepanov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
When compiling this program:
int main()
{
struct {
int x;
int y[];
} s;
12345 && &s.y + 1;
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
While compiling such program:
int main()
{
"abc" == "def";
}
I get this warning:
$ gcc -Wall -Wno-un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70772
--- Comment #1 from Alexander Cherepanov ---
clang bug -- https://llvm.org/bugs/show_bug.cgi?id=27495 .
1 - 100 of 176 matches
Mail list logo
