http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Tue Oct 29 13:15:48 2013
New Revision: 204159
URL: http://gcc.gnu.org/viewcvs?rev=204159&root=gcc&view=rev
Log:
2013-10-29 Marc Glisse
PR tree-optimization/58689
include/
* ansi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #19 from Marc Glisse ---
Author: glisse
Date: Tue Oct 29 13:19:08 2013
New Revision: 204160
URL: http://gcc.gnu.org/viewcvs?rev=204160&root=gcc&view=rev
Log:
2013-10-29 Marc Glisse
PR tree-optimization/19831
gcc/
* tree-ss
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f(){
int i __attribute__((vector_size(2*sizeof(int = { 2, 3 };
__builtin_shuffle (i, i);
}
g++-4.8:
x.c:3:3: warning: statement has no effect
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
double a[10];
bool f(int n){
a[3]=42;
__builtin_memset(&a[n],3,sizeof(double));
return a[3]==42;
}
is optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58834
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Fri Nov 1 15:23:24 2013
New Revision: 204296
URL: http://gcc.gnu.org/viewcvs?rev=204296&root=gcc&view=rev
Log:
2013-11-01 Marc Glisse
PR c++/58834
gcc/cp/
* pt.c (type_dependen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58834
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Marc Glisse changed:
What|Removed |Added
Keywords|ice-on-valid-code, |
|rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #2 from Marc Glisse ---
When I introduced RO_ARROW_STAR I didn't realize it could end up in
invalid_indirection_error, probably just needs an extra "case" there.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> Well, what does OpenCL specify here?
"The logical operators and (&&), or (||) operate on all scalar and vector
built-in types. For scalar built-in types only, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #10 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #9)
> Thus no short-circuiting for vector && or ||.
Indeed. Though we already deviated from OpenCL for ?: and as mentioned in my
patch we could do short-circuit for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58958
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Tue Nov 5 13:01:06 2013
New Revision: 204389
URL: http://gcc.gnu.org/viewcvs?rev=204389&root=gcc&view=rev
Log:
2013-11-05 Marc Glisse
PR tree-optimization/58958
gcc/
* tree-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58958
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
--- Comment #3 from Marc Glisse ---
(In reply to Matthew Leach from comment #1)
> Having a quick dig around the code, I think fold-const.c:16718 looks
> suspicious:
>
> if (offset/part_widthi <= TYPE_VECTOR_SUBPARTS (op00type))
>
> Likewise in c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #11 from Marc Glisse ---
memcmp is pure and gcc manages to pull it out of the loop (see the file created
by -fdump-tree-optimized). It is funny that -fno-builtin-strcmp makes the code
more than 2 times faster (the main difference I can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
--- Comment #1 from Marc Glisse ---
For the vectorizer issue on trunk, this is enough:
int printf (const char *, ...);
short b = 0;
int
main ()
{
int c = 0;
l1:
b++;
c |= b;
if (b)
goto l1;
printf ("%d\n", c);
return 0;
}
Thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
--- Comment #5 from Marc Glisse ---
(In reply to vries from comment #4)
> Tentative patch:
> ...
> diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
> index 93b8970..6f2b4fb 100644
> --- a/gcc/tree-ssa-forwprop.c
> +++ b/gcc/tree-ssa-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #15 from Marc Glisse ---
Related PRs involving || and && for vectors: PR 57198 and PR 58845.
PR 58845 contains information about having a sequence point in the
gimplification of those operators.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032
--- Comment #3 from Marc Glisse ---
I wonder if it would take more than replacing:
inc = integer_one_node;
with something like:
inc = VECTOR_TYPE_P (argtype)
? build_one_cst (argtype)
: intege
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #7 from Marc Glisse ---
(In reply to Joost VandeVondele from comment #6)
> Marc, I think your recently posted patch:
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html
> could fix the problem with the testcase subroutine S1, eve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #9 from Marc Glisse ---
(In reply to Joost VandeVondele from comment #8)
> Marc, looks like the fortran FE changed a lot since this bug was filed, and
> there is no explicit allocate anymore, in fact the variable is created on
> stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #11 from Marc Glisse ---
(In reply to Joost VandeVondele from comment #10)
> (In reply to Marc Glisse from comment #9)
> > Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my
> > current patch would handle it. It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59032
--- Comment #5 from Marc Glisse ---
(In reply to vries from comment #4)
> I've tried to do something similar in cp_build_unary_op. Tentative patch:
That seems very complicated. We know the arguments, so we know which has to be
converted to what.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Doc and prototype for function better_state in ipa-pure-const.c:
/* Merge STATE and STATE2 and LOOPING and LOOPING2 and store
into STATE and LOOPING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #1 from Marc Glisse ---
That's an extension, it is done on purpose for compatibility with C code. IMHO
the standard's decision to replace C's complex.h with something completely
unrelated was nonsense.
Did that cause real problems for
||2013-11-12
CC||glisse at gcc dot gnu.org
Summary|including complex.h in |Issues including complex.h
|C++11/1y mode should not|in C++11/1y mode because of
|include C's comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59100
--- Comment #1 from Marc Glisse ---
IIRC we already added another safe rotate form this year based on a report by
Niels, you may want to search for that (maybe in the comment before
simplify_rotate in tree-ssa-forwprop.c).
Basically you are askin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077
--- Comment #1 from Marc Glisse ---
Author: glisse
Date: Wed Nov 13 11:55:01 2013
New Revision: 204739
URL: http://gcc.gnu.org/viewcvs?rev=204739&root=gcc&view=rev
Log:
2013-11-13 Marc Glisse
PR tree-optimization/59077
* ipa-pure-cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Wed Nov 13 15:47:04 2013
New Revision: 204750
URL: http://gcc.gnu.org/viewcvs?rev=204750&root=gcc&view=rev
Log:
2013-11-13 Marc Glisse
PR libstdc++/59087
* include/ext/pod_char_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59116
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800
Marc Glisse changed:
What|Removed |Added
CC||chandraprakashblr at gmail dot
com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59128
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #8 from Marc Glisse ---
(In reply to Ed Smith-Rowland from comment #7)
> g++ is working as intended.
Thanks a lot for the investigation. Do you think the error message: "unable to
find numeric literal operator" could additionally poin
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
(I haven't seen a category for transactional memory)
In trans-mem.c, function diagnose_tm_1 has:
if (flags_from_decl_or_type (fn) & ECF_T
: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-unknown-linux-gnu
double f(double x){
asm volatile("":"+X"(x));
return x;
}
double g(double x,double y){
return f(f(x)+f(y));
}
compile
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-unknown-linux-gnu
double f(double x){
asm volatile("":"+f"(x));
return x;
}
a.c: I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155
--- Comment #1 from Marc Glisse ---
By the way, the following:
double f(double x){
asm volatile("":"+X"(x));
return x;
}
double g(){
return f(1.);
}
is rejected with:
c.c: In function 'g':
c.c:2:3: error: inconsistent operand constraints
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
(category:c because I am asking for a built-in, but this is more about
middle/back-end)
Since gcc doesn't support FENV, I often need to insert optimization barriers in
my code that hide t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
--- Comment #2 from Marc Glisse ---
(In reply to jos...@codesourcery.com from comment #1)
> On Sun, 17 Nov 2013, glisse at gcc dot gnu.org wrote:
>
> > propagation, or replace x*-y with -x*y, or move operations across
> > f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59157
--- Comment #4 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #2)
> > long double f(long double x){
> > asm volatile("":"+mf"(x));
>
> "+t"(x) should be used here.
That's not really the same thing. The idea is that if I have:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
Marc Glisse changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
riority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
static double f(double x){asm volatile("":"+tg"(x));return x;}
double g(double a,double b,double c){
retu
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
double f(double x){asm volatile("":"+xt"(x));return x;}
error: output cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
ation
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
#include
int f(){
std::atomic_int i(0);
++i;
--i;
return i;
}
As in PR 48987, I would like t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50123
--- Comment #3 from Marc Glisse ---
Is this fixed or do we want a tree-level optimization replacing one builtin
with a simpler one?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59209
--- Comment #1 from Marc Glisse ---
In test_copy2, we get:
_2 = x_1(D) + 1;
src_end.1_8 = (long int) _2;
src_start.2_9 = (long int) x_1(D);
_10 = src_end.1_8 - src_start.2_9;
_11 = (long unsigned int) _10;
This reminds me of PR 58742:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #14 from Marc Glisse ---
So we don't forget it, PR 59209 asks to simplify:
(ptr+size)-ptr to size
not just:
ptr1+(ptr2-ptr1) to ptr2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
--- Comment #1 from Marc Glisse ---
Similar to PR 53017 (does the same +0 workaround work?). The main difference
with constructor seems to be a call to default_conversion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221
Marc Glisse changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
--- Comment #6 from Marc Glisse ---
Uros, I can't seem to find the AMD documentation anymore (marketing has gotten
hold of the website and tech info got hidden somewhere deep), but if I remember
correctly, vfrczsd %xmm0, %xmm1 does:
xmm0[0]=frcz(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
--- Comment #7 from Marc Glisse ---
Ah no, I was wrong, sorry about that:
The VFRCZSS and VFRCZSD instructions extract the fractional portion of the
single-/double-precision scalar floating-point value in an XMM register or 32-
or 64-bit memory l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
--- Comment #10 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #9)
> Patch that fixes _mm_frcz_{ss,sd} intrinsics
Looks good (assuming the detailed description is more correct than the
high-level one in AMD's doc), thank you.
Arguabl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
--- Comment #12 from Marc Glisse ---
(In reply to Uroš Bizjak from comment #11)
> I left the prototype the way it was.
Makes sense to me.
> Marc, since it looks you have access to XOP target (I don't have one), can
> you please write an XOP test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #12 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #9)
> Yeah, exactly. Still if there is a sequence point at && or ||
> (even if both arms are always executed) then the order of evaluating
> side-effects is importan
-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
//void foo (void) { }
void func3 (char *) __attribute__((constructor(foo)));
This ICEs in C (not in C++) because of the call
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
enum class E : int { prio = 666 };
void f (int) __attribute__((constructor(E::prio)));
is accepted with -std=c++11 whereas the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
--- Comment #4 from Marc Glisse ---
(In reply to Daniel Krügler from comment #3)
> IMO the explicit conversion is necessary here and the fact that it doesn't
> work without it is not a bug. Note that a scoped enumeration type does not
> implicitly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #2 from Marc Glisse ---
For __builtin_shuffle, the issue is that we now call save_expr, which always
sets TREE_SIDE_EFFECTS to 1. I don't know if it would make sense to introduce a
maybe_save_expr that is equivalent to save_expr but do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #4 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #3)
> You could decorate __builtin_shuffle with attribute "warn_unused_result". It
> is not the same, but it probably more precise. It would also warn for:
> __built
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #6 from Marc Glisse ---
For:
void f(){
int i = 2;
(i+i);
}
we always set TREE_NOWARNING in finish_parenthesized_expr. The comment next to
it says this is to avoid warning in c_common_truthvalue_conversion. If that's
the only reas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #7 from Marc Glisse ---
Created attachment 31342
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31342&action=edit
patch
The __builtin_shuffle part of the patch seems fine.
For (i+i), I first tried not setting TREE_NOWARNING on t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #8 from Marc Glisse ---
(In reply to Eric Botcazou from comment #5)
> > For __builtin_shuffle, the issue is that we now call save_expr, which always
> > sets TREE_SIDE_EFFECTS to 1. I don't know if it would make sense to
> > introduce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59358
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #14 from Marc Glisse ---
Created attachment 31343
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31343&action=edit
WIP
Let me attach this here. save_expr+build_vector_from_val is unnecessary, the
BIT_*_EXPR case would handle it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> I think BIT_FIELD_REF's type can't be a vector,
Er, I am quite sure a BIT_FIELD_REF can be a vector. Maybe that wasn't a
general statement and I missed the context?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> You mean BIT_FIELD_REF argument can be a vector? Sure. But the type of the
> BIT_FIELD_REF itself?
Yes, the type of the BIT_FIELD_REF itself. A quick grep gives:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545
--- Comment #1 from Marc Glisse ---
Dup of PR 57324? (yes, I know, gcc vs clang)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59622
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633
--- Comment #1 from Marc Glisse ---
What makes you think the code is valid? From the doc, I think this should be
rejected (with a proper error message).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615
--- Comment #6 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> Anyway, you definitely don't want
> to use inline asm in this case, if there is some code GCC doesn't optimize
> as good as you'd like to, just report that.
One com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #7)
> They are modelled in the .md files now, we just don't have general purpose
> builtins for this yet in GCC 4.9, it is only used for -fsanitize=undefined
> right now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59641
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59642
--- Comment #1 from Marc Glisse ---
I've noticed the same in other PRs, normally we manage to track the actual
value of *p, but we don't manage that when *p was written by __builtin_mem*,
which should still be doable:
int f(int*p){
__builtin_mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954
Marc Glisse changed:
What|Removed |Added
CC||ylow at graphlab dot com
--- Comment #12 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633
--- Comment #3 from Marc Glisse ---
(In reply to Volker Reichelt from comment #2)
> Well, because the C-frontend compiles it, the C++-frontend used to compile
> it and even clang (3.2) compiles it, I was under the impression that this
> should com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59642
--- Comment #2 from Marc Glisse ---
(In reply to Marc Glisse from comment #1)
> I've noticed the same in other PRs, normally we manage to track the actual
> value of *p, but we don't manage that when *p was written by __builtin_mem*,
> which shoul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #4 from Marc Glisse ---
Created attachment 31564
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31564&action=edit
patch
(mostly untested)
This changes the message to:
error: call of overloaded 'f(NT&)' {aka 'f(unsigned int&)'} i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
--- Comment #8 from Marc Glisse ---
Author: glisse
Date: Thu Jan 2 22:26:24 2014
New Revision: 206300
URL: http://gcc.gnu.org/viewcvs?rev=206300&root=gcc&view=rev
Log:
2014-01-02 Marc Glisse
PR c++/59378
gcc/cp/
* typeck.c (build_x_v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59378
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59641
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Thu Jan 2 22:43:24 2014
New Revision: 206303
URL: http://gcc.gnu.org/viewcvs?rev=206303&root=gcc&view=rev
Log:
2014-01-02 Marc Glisse
PR c++/59641
gcc/cp/
* call.c (build_condi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #9 from Marc Glisse ---
Author: glisse
Date: Thu Jan 2 22:45:56 2014
New Revision: 206304
URL: http://gcc.gnu.org/viewcvs?rev=206304&root=gcc&view=rev
Log:
2014-01-02 Marc Glisse
PR c++/59087
gcc/cp/
* parser.c (cp_parser
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59641
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087
--- Comment #10 from Marc Glisse ---
It seems to me that this is ok now.
* If you want , include that, not
* contains the C stuff for compatibility with C code, C code
doesn't include , so doesn't need that stuff (it wouldn't
make sense to mov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #6 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Marc Glisse from comment #4)
> There is code in error.c:type_to_string to print "{aka ". It does some
> tricks to avoid printing aka when there ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #11 from Marc Glisse ---
(In reply to Jason Merrill from comment #10)
> (In reply to Marc Glisse from comment #7)
> > The __builtin_shuffle part of the patch seems fine.
>
> Yes, that looks right. That fixes the bug, yes?
It fixes t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #1 from Marc Glisse ---
Well, that's a glibc issue, isn't it?
Btw, you need to provide the preprocessed code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #12 from Marc Glisse ---
Author: glisse
Date: Fri Jan 3 21:12:48 2014
New Revision: 206325
URL: http://gcc.gnu.org/viewcvs?rev=206325&root=gcc&view=rev
Log:
2014-01-03 Marc Glisse
PR c++/58950
gcc/cp/
* cvt.c (convert_to_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
Marc Glisse changed:
What|Removed |Added
Summary|[4.9 Regression] Missing|Missing "statement has no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88499
--- Comment #2 from Marc Glisse ---
I don't think using fenv.h with -ffast-math makes much sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #2 from Marc Glisse ---
As someone who regularly has to debug complicated template code, I think all
the information printed by g++ here is useful. There may be more compact ways
of giving the same information (use a shorthand for
"st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88512
--- Comment #4 from Marc Glisse ---
(In reply to Jonny Grant from comment #3)
> Updated output I had executed from STL with clear candidate suggestions:
>
> $ g++ -Wall -o stl_string stl_string.cpp
> stl_string.cpp: In function ‘int main()’:
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #10 from Marc Glisse ---
IMO -Wmaybe-uninitialized should not be enabled by -Wall, whatever the
optimization level (even at -O3), it has too many false positives that are all
but impossible to work around (thus violating the definitio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
--- Comment #14 from Marc Glisse ---
(In reply to Jeffrey A. Law from comment #12)
> Whether or not to fix as well as whether or not to warn at -O0 are a topic
> of debate. I'm not sure I'm up for re-opening that can of worms right now.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88598
--- Comment #1 from Marc Glisse ---
-funroll-loops helps (I expect that's what llvm does).
float j[5] = {}; also helps. We should probably simplify {0,0,...} to {}, but
then we would still be missing the optimization for {1,1,...} where we would
701 - 800 of 2561 matches
Mail list logo
