https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #23 from Marc Glisse ---
(In reply to Harald Anlauf from comment #3)
> subroutine gfcbug138 (yerrmsg)
> character(kind=1,len=*) :: yerrmsg
> yerrmsg = 1_"bug: " // yerrmsg
> end subroutine gfcbug138
[...]
> gfcbug138 (character(ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #25 from Marc Glisse ---
(In reply to Dominique d'Humieres from comment #24)
> The following variant does not give the warning
That's because the code has become obfuscated enough that we don't have the
simplification l-(l+5) anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83158
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164
--- Comment #2 from Marc Glisse ---
Does it work if you remove the verification
|| !types_compatible_p (rhs1_type, rhs2_type)
from tree-cfg.c?
useless_type_conversion_p says that converting a function pointer to char* is
useless (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164
Marc Glisse changed:
What|Removed |Added
CC||skpgkp1 at gmail dot com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83166
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83165
--- Comment #1 from Marc Glisse ---
Could you explain why this code should be accepted, to save time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194
--- Comment #2 from Marc Glisse ---
What if strcmp returns INT_MIN?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> The "proper" result for [MIN,MAX] | 1 is of course a set of every odd
> number...
Sadly, while we track may-be-nonzero bits in CCP (maybe with the VRP reorg
there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #6 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> we miss to optimize (int)((short int)((unsigned short) x1.1_4 ^ 8) & 1) to
> (int)(x1.1_4 & 1) as well.
(untested)
+/* (X |^ 8) & 1 --> X & 1 */
+(for op (bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #1 from Marc Glisse ---
It is strongly related to the other PRs. IMO, all warnings like
maybe-uninitialized should move from Wall to Wextra, but that's going to be a
hard sell.
In the mean time, we fail to find some VRP optimizations
ion
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This code is based on basic_string_view::_S_compare, which should probably be
impro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83240
--- Comment #4 from Marc Glisse ---
(this PR is vaguely related to PR 57974)
Unrelated, but I am surprised we don't end up computing at compile-time in this
example. We vectorize sqrt before unrolling the first loop and getting the
constants. An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #4 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> In the mean time, we fail to find some VRP optimizations that might help
> with the warning.
>
> _1 = _186 + 18446744073709551614;
> if (_1 > _186)
>
> _186: [3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
--- Comment #3 from Marc Glisse ---
This warning is "less wrong" than the other related ones. If frame_size is 0,
this does call memset(,,-1). And there is an explicit test for frame_size == 0
in the function, which makes it look like 0 is not su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83262
--- Comment #1 from Marc Glisse ---
What version of gcc, and what platform? With gcc-8 on x86_64 (skylake), I get
GOTO costs totally 0.904 (s)
SELECT CASE costs totally 0.704 (s)
IF-Goto costs totally 0.706 (s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79119
--- Comment #2 from Marc Glisse ---
With POINTER_DIFF_EXPR, things may be easier. One of the things I suggested
when introducing it was that VRP could always use a range of [ -PTRDIFF_MAX,
PTRDIFF_MAX ] for them. If you had written
__PTRDIFF_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83296
--- Comment #1 from Marc Glisse ---
Note that -fdump-tree-optimized-all includes the range information in the dump.
Normally, we know how to derive a range for MAX_EXPR, but in this case the
MAX_EXPR only appears in phiopt3, later than VRP2. On t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83299
--- Comment #1 from Marc Glisse ---
As an implementation detail, the argument to POINTER_PLUS is always unsigned...
(maintainers are in favor of changing that, but someone needs to do the work)
Also, we now quickly simplify p-q to -i, which lose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164
--- Comment #11 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 42810 [details]
> gcc8-pr83164.patch
Sorry, I shouldn't have taken this long.
> So like this? It makes no sense to call types_compatible_p or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312
--- Comment #1 from Marc Glisse ---
Ironically, it seems to be the same pass, VRP1, that warns that some piece of
code accesses pd_threads[j] for some negative j and later notices that the
corresponding path is dead. I don't know if we can shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438
--- Comment #1 from Marc Glisse ---
Gcc does avoid using the stack when it is more efficient to do so (depends on
the -march setting).
Yes, using SSE would be better.
The general advice is to stop using MMX.
Using gcc's vector extension generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244
--- Comment #4 from Marc Glisse ---
(In reply to Andrew Pinski from comment #3)
> On the trunk (on aarch64) we get:
Yes, on I32P64 platforms we still have a chance to prove that the
multiplication doesn't overflow.
> long int _4;
> long int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77475
Marc Glisse changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77544
--- Comment #3 from Marc Glisse ---
302806 >> 0 should have been folded first, so we are apparently calling fold on
unfolded operands somewhere?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77591
--- Comment #2 from Marc Glisse ---
Before delayed folding, the conditional was probably eliminated before we even
reached the warning code in the front-end. The warning is duplicated in the
middle-end precisely because in some cases we need opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #19 from Marc Glisse ---
(In reply to Andrew Pinski from comment #17)
> I think this is fixed for GCC 7 with -std=c++17 support.
No, it isn't. new T[10] will give suitably aligned memory, but not
std::allocator. Only the core part of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #22 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #20)
> In C++17 std::allocator no longer says "It is implementation-defined whether
> over-aligned types are supported" and is no longer required to call operator
> ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77745
--- Comment #3 from Marc Glisse ---
I think the issue is with
Deleted redundant store MEM[(long int *)c2_7(D)] = 200;
It is considered as redundant with
MEM[(long long int *)c2_7(D)] = 200;
but they do not define the same dynamic type, so it
Assignee: ian at airs dot com
Reporter: glisse at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Build: powerpc64le-unknown-linux-gnu
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
In crtstuff.c, function deregister_tm_clones contains this code:
if (__TMC_END__ - __TMC_LIST__ == 0)
this currently gives, in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813
--- Comment #1 from Marc Glisse ---
Created attachment 39728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39728&action=edit
optimization patch that shows the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59650
--- Comment #2 from Marc Glisse ---
Actually, we have a regression, BIT_INSERT_EXPR causes a spurious warning
a.c:13:10: warning: 'tmp' is used uninitialized in this function
[-Wuninitialized]
tmp[0] = v[0];
~~~^~
And we don't vec
iority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
unsigned f(unsigned x){ return (x>>4)*16; }
gives the optimized dump
_1 = x_2(D) >> 4;
_3 = _1 * 16;
while (x/16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77836
--- Comment #2 from Marc Glisse ---
(In reply to Andrew Pinski from comment #1)
> The easy way to do this is to canonicalize the shift to a multiply or the
> multiply to a shift which is what it is done on the RTL level.
For unsigned types that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77858
--- Comment #1 from Marc Glisse ---
The standard says
"Requires: rho shall be non-negative and non-NaN. theta shall be finite."
(I wasn't in favor of it, seems gratuitous, but if you want to complain about
the standard, this isn't the right place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899
--- Comment #9 from Marc Glisse ---
I don't see what "signed" has to do with it.
void f (unsigned char i)
{
char d [1260];
const char *p = &d[130];
p += i;
if (p < d + 2 || d + 757 < p)
__builtin_abort ();
}
We don't optimize thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #3 from Marc Glisse ---
(In reply to Martin Sebor from comment #2)
> I may also be confused about other things but below is what I see in GDB
> when I call get_range_info() from plus_stmt_object_size() on the offset in
> POINTER_PLUS_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #5 from Marc Glisse ---
(In reply to Martin Sebor from comment #4)
> I suppose I was expecting that that after EVRP (and before VRP1)
> get_range_info() would either succeed and return a range representing a
> subrange of the the vari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #7 from Marc Glisse ---
(In reply to Martin Sebor from comment #6)
> I meant a subrange of the i variable (i.e., a subrange of int). The range
> of every variable is necessarily bounded by its type so returning a range of
> [INT_MIN,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #9 from Marc Glisse ---
(In reply to Martin Sebor from comment #8)
> I agree that in many cases there isn't enough information to tell that a
> range is final and can't be further improved. But there certainly are such
> cases (the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964
--- Comment #11 from Marc Glisse ---
(In reply to Andrew Pinski from comment #5)
> Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for
> __start_builtin_fw and __end_builtin_fw
Shouldn't we recommend "+g" instead of "+r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77980
--- Comment #1 from Marc Glisse ---
To simplify 1/n to 0, we would have to notice that n cannot be ±1 (the last bit
is zero since n is 2*x2), and it cannot be 0 either in that division. That
seems quite specialized, but rather easy to add to matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77980
--- Comment #3 from Marc Glisse ---
Note that "regression in gcc-7.0.0" would mean that gcc-6 was doing better,
which is not the case.
: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
i/a.h:
#define foo bar
x.c:
#include
int main(){
foo(42);
}
$ gcc x.c -isystem i -c
$ gcc x.c -I i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> This is undesirable, iftmp.0_2 really isn't constant, so we shouldn't turn
> it into sometimes constant, sometimes non-constant.
I am not sure about that. The way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #9 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #8)
> I've spent a goodly part of the morning pondering this BZ. While I think
> the semantics of b_c_p are under/ill defined and they will continue to cause
> problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78071
--- Comment #3 from Marc Glisse ---
Dup of PR 70777? I can reproduce with gcc-6 but not with gcc-7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> This means using GCC vector extensions in the header for the intrinsic was
> a bad idea in this particular case.
Yes, the simplest fix is to revert to using the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #16 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> Or, if we are ok that for SSE4.1 (and not SSE4.2) the vectorizer just won't
> be able to use those V2DI equality (and gt?) comparisons, then revert part
> of the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78115
--- Comment #2 from Marc Glisse ---
For the first part, when we transform (X+C1)+C2 to X+(C1+C2), we check that
C1+C2 doesn't overflow. But if C1+C2 would give INT_MIN, we still have the
possibility to generate X-INT_MIN without going to an unsig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78130
--- Comment #7 from Marc Glisse ---
Reduced a bit more:
struct B {
B();
void m_fn2(int p1) {
if (p1 <= storage_)
throw;
}
int storage_;
};
void f() {
B span_;
int b = span_.storage_;
span_.m_fn2(b - 1);
}
The warning see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78146
--- Comment #2 from Marc Glisse ---
PR 77948 ?
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from a discussion in the comments of
http://stackoverflow.com/a/40284138/1918193)
#include
#include
int return_min(std::vector &a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62191
--- Comment #1 from Marc Glisse ---
vector(4) int _4;
_4 = x_1(D) >> 31;
_5 = VIEW_CONVERT_EXPR(_4);
_6 = _5 >> 31;
(lshiftrt (ashiftrt X N) 31) is just (lshiftrt X 31)
The scalar case is handled in combine, probably by simplify_shift_c
: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
From http://stackoverflow.com/q/39947582/1918193
void testfunc_flat(double a, double b, double* dst)
{
dst[0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78203
--- Comment #4 from Marc Glisse ---
> In my opinion, the warning should be given
Nobody contradicted you, we agree that it would be good to issue the warning.
We already know about this issue (there are duplicates you can search for in
bugzilla)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78218
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295
Marc Glisse changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78302
--- Comment #1 from Marc Glisse ---
See also PR 71301.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78305
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78327
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78399
--- Comment #2 from Marc Glisse ---
Related to PR 50384.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
--- Comment #1 from Marc Glisse ---
Do you think you could produce a smaller, stand-alone testcase that reproduces
the issue? Or at least attach the preprocessed sources to the report?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
--- Comment #6 from Marc Glisse ---
I don't think this is related to the loop, a = b = (struct buf) {} loses the
assignment to b even if you put it alone on its line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Sun Nov 20 13:35:27 2016
New Revision: 242635
URL: https://gcc.gnu.org/viewcvs?rev=242635&root=gcc&view=rev
Log:
Protect __TMC_END__ - __TMC_LIST__ == 0
2016-11-20 Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77813
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
--- Comment #1 from Marc Glisse ---
Some things that help:
-fabi-version=0
-fwhole-program (so it knows emplace_back won't be used anywhere else, and it
can inline it and remove the unneeded paths)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
--- Comment #1 from Marc Glisse ---
For function definitions (nothing to do with templates) the attribute has to
come at the beginning, not at the end. Move it right before 'static' and it
will compile.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60637
--- Comment #2 from Marc Glisse ---
IIUC (with gcc-4.9), signbit is not part of C++98, and with -std=c++11 things
work. In C++98 mode, libstdc++ (sometimes) provides std::signbit as an
extension, which calls __builtin_signbit which takes a double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #4 from Marc Glisse ---
uostream ucout;
Where did you see in the standard that basic_ostream is default constructible?
The only constructor I can find is the explicit one from basic_streambuf*.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60711
--- Comment #12 from Marc Glisse ---
Before saying that there is a problem with libstdc++, did you try other
implementations? clang++ with libc++ gives the same error. That's just not how
streams are supposed to be used (pretend it is a pure virtu
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
the following seems already fixed in 4.9, but it would be great to backport it
(I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769
--- Comment #1 from Marc Glisse ---
Still present with a pure r209150.
0x98bcc9 lra_constraints(bool)
/data/repos/gcc/gcc-4_8-branch/gcc/lra-constraints.c:3563
0x97c676 lra(_IO_FILE*)
/data/repos/gcc/gcc-4_8-branch/gcc/lra.c:2278
0x937a82
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
looking at Manuel's testcase from PR 60517, I notice that EINLINE changes:
D.2253 = A::getB (&a);
to:
D.2264 = a.b;
D.2263 = D.2264;
D.2253 = D.2263;
(several copies, but only the o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #10 from Marc Glisse ---
Created attachment 32549
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32549&action=edit
first try
With -O -fdisable-tree-esra (see PR 60770), it warns on the testcase. Twice
because the DSE pass is run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #1 from Marc Glisse ---
int f(int n){
int*p;
{
int q=n;
p=&q;
}
return *p;
}
Here CCP turns:
q = n_2(D);
p_4 = &q;
q ={v} {CLOBBER};
_6 = *p_4;
into:
q_5 = n_2(D);
_6 = q_5;
I guess relying on clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
Marc Glisse changed:
What|Removed |Added
Attachment #32549|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #13 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #12)
> Why do you want to remove the clobber?
I am in the DSE pass, so removing the clobber as a dead store is the easiest
thing to do ;-)
Ok, it might not be su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #4 from Marc Glisse ---
Catching it earlier may be hard, even for these trivial examples we only have
from einline (18) to esra (24) or from eh (10) to ccp1 (21) and in more
complicated examples I fear the interval will be empty, but w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #14 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #13)
> It is not clear to me why you want to print at all. It is an
> internal detail.
Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone
s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769
--- Comment #5 from Marc Glisse ---
Thanks!
(not closing because of Jakub's comment, but it is working fine now)
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
#include
int f (__m64 const __A, int const __N)
{ return ((__v4hi)__A)[__N]; }
compiler with -O2, produces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #5 from Marc Glisse ---
typedef int v2si __attribute__((vector_size (8),may_alias));
typedef short v4hi __attribute__((vector_size (8),may_alias));
int f (v2si __A, int __N)
{ return (*(v4hi*)&__A)[__N]; }
also fails.
Reading the doc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #8 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #6)
> Not exactly - it's again the wrapping that will fail.
That seems strange to me. From the doc of may_alias:
"Accesses through pointers to types with this attrib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #10 from Marc Glisse ---
Ah. So, from a user's POV, it should be valid. But internally, we convert
v2si*->v4hi* (ok), v4hi*->short* (ok), we forget the intermediate step, and we
end up with v2si*->short*, which is not ok since the type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #11 from Marc Glisse ---
(In reply to Marc Glisse from comment #10)
> Maybe the patch from comment #9 could be restricted to the case where the
> vector type has may_alias?
Oups, that's already the case, sorry for misreading.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59434
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Fri Apr 11 19:23:49 2014
New Revision: 209323
URL: http://gcc.gnu.org/viewcvs?rev=209323&root=gcc&view=rev
Log:
2014-04-11 Marc Glisse
PR libstdc++/59434
* include/bits/stl_iter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59434
Marc Glisse changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60829
--- Comment #2 from Marc Glisse ---
(In reply to arm.nahm from comment #0)
> The above code compiles in g++,
No it doesn't. Please make sure to copy-paste directly from a file you have
tested.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819
--- Comment #12 from Marc Glisse ---
Created attachment 32586
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32586&action=edit
Richard's small patch
I regtested it (patch from comment #9 plus a testcase) on x86_64-linux-gnu and
it passed. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459
Marc Glisse changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60831
--- Comment #2 from Marc Glisse ---
(In reply to mmokrejs from comment #0)
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> pdpe1gb rdtscp lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459
--- Comment #2 from Marc Glisse ---
(In reply to Marek Polacek from comment #1)
> The problem on the C side of things is that the values of the enum are
> represented by CONST_DECL nodes and check_user_alignment doesn't look
> through it. So mayb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50459
--- Comment #4 from Marc Glisse ---
Creating a function definitely makes sense, I should have done it when I
touched the default_conversion calls. Do you think your function could also
handle the call to default_conversion (with the tests that pro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60852
--- Comment #15 from Marc Glisse ---
Did someone file a corresponding PR for clang? It is useful for them, but also
for gcc because it gives them a chance to give a different interpretation of
the standard.
1801 - 1900 of 2562 matches
Mail list logo
