https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
--- Comment #4 from Marc Glisse ---
Seems strongly related to PR55266 (which also references PR52436).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64786
--- Comment #1 from Marc Glisse ---
See also PR53294 and PR64501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Marc Glisse changed:
What|Removed |Added
Severity|major |normal
--- Comment #1 from Marc Glisse --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #3 from Marc Glisse ---
(In reply to Conrad from comment #2)
> Notwithstanding loopholes in C++ legalese,
No loopholes, this was a deliberate choice in C.
> the expected result is to
> evaluate things left to right, just like readin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
Marc Glisse changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Marc Glisse ---
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #2 from Marc Glisse ---
IMHO the only sensible solution is in this direction:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
I hope Clark is still working on this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #4 from Marc Glisse ---
(In reply to Benoit Jacob from comment #3)
> I'd be interested in an explanation of why the default STL allocator can't
> just honor the alignment of the value_type ?
[allocator.members] "It is implementation-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #7 from Marc Glisse ---
(In reply to Benoit Jacob from comment #6)
> I would still be interested in how you understand 3.11/9
I consider it a defect in the standard, so it needs fixing, not
understanding...
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target: x86_64-linux-gnu
I am compiling the following with: g++ -std=gnu++11 -Ofast
#include
extern const __m128i x = { -1, 0 };
extern const __m128i y = _mm_set_epi64x (0, -1);
While
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59948
--- Comment #7 from Marc Glisse ---
There has been huge progress in gcc-5:
int m() ()
{
struct function h;
:
MEM[(int (*) (int) *)&h] = f;
h._M_invoker = _M_invoke;
h.D.27699._M_manager = _M_manager;
std::_Function_base::_Base_manag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216
--- Comment #2 from Marc Glisse ---
The ranges are wrong before VRP2. Reassoc2 does something suspicious...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65275
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63496
--- Comment #1 from Marc Glisse ---
I don't know if it is the same one (strange line number):
return offset + GET_MODE_BITSIZE (Pmode) <= offset
(missing tci-> on the first offset probably)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500
--- Comment #1 from Marc Glisse ---
(In reply to Wouter Vermaelen from comment #0)
> Is the following a bug in the debug version of std::make_move_iterator or is
> it a bug in my code? It compiles fine with older gcc versions (both debug
> and no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500
--- Comment #4 from Marc Glisse ---
Would it make sense to overload __addressof so it accepts any glvalue? In
practice, that means also accepting prvalue...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28367
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
--- Comment #3 from Marc Glisse ---
According to Joseph's explanation at
https://sourceware.org/bugzilla/show_bug.cgi?id=17441 , this transformation
should be conditional to !flag_signaling_nans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506
--- Comment #2 from Marc Glisse ---
Do you mean decltype(*it) (without the extra parentheses) everywhere?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Mon Oct 13 10:00:27 2014
New Revision: 216142
URL: https://gcc.gnu.org/viewcvs?rev=216142&root=gcc&view=rev
Log:
2014-10-13 Marc Glisse
PR libstdc++/61347
PR libstdc++/63345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345
--- Comment #6 from Marc Glisse ---
Author: glisse
Date: Mon Oct 13 10:00:27 2014
New Revision: 216142
URL: https://gcc.gnu.org/viewcvs?rev=216142&root=gcc&view=rev
Log:
2014-10-13 Marc Glisse
PR libstdc++/61347
PR libstdc++/63345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #9 from Marc Glisse ---
I'd rather work on improving the warnings so we can tell the user how bad his
code is, but in case, we had a similar request in GMP, a code that was inspired
by libstdc++ valarray:
https://gmplib.org/list-arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #22 from Marc Glisse ---
There were some comments by Florian:
https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00149.html
I don't think the patch was ever pinged during stage 1, worth another try...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63537
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> Eventually a simple pass could handle
>
>= ret;
> ret ={v} {CLOBBER};
> return ;
>
> and back-propagate into all stores/loads of ret.
Shouldn't tree-nr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> Btw, what was the original testcase?
Sorry, I don't remember. Probably something involving std::vector or
std::string. Since llvm optimizes it just fine, I hadn't
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
I am getting a bit sick of all the artificial base classes invented just so we
can benefit from the empty base optimization when we actually want a member. I
believe an attribute would be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63579
--- Comment #1 from Marc Glisse ---
Created attachment 33750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33750&action=edit
Hack to handle empty members as bases
ion
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
unsigned f(unsigned x){
unsigned y = x + x;
y = y + x;
y = y + x;
y = y + x;
y = y + x;
y = y + x;
y = y + x;
return y;
}
The .optimized dump still shows:
y_2 = x_1(D) + x_1(D);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63599
--- Comment #3 from Marc Glisse ---
ifcvt making a transformation that doesn't help vectorization and ends up
pessimizing the code... not really the first time this happens. I believe Jakub
had a big patch for that, but it never got in. Maybe vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #5 from Marc Glisse ---
Another example:
#include
void f(){
const int n=1<<14;
double a[n];
double b[n];
double c[n];
__builtin_memset(a,0,n);
__builtin_memset(b,0,n);
__builtin_memset(c,0,n);
for(int i=0;i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666
--- Comment #12 from Marc Glisse ---
(I am traveling this week, so I can only post a short comment)
(In reply to Richard Biener from comment #11)
> - if (need_mask_canon && arg2 == op2)
> + if (need_mask_canon && arg2 == op2
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63666
--- Comment #13 from Marc Glisse ---
Author: glisse
Date: Mon Nov 3 10:36:35 2014
New Revision: 217033
URL: https://gcc.gnu.org/viewcvs?rev=217033&root=gcc&view=rev
Log:
2014-11-03 Marc Glisse
PR tree-optimization/63666
* fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #10 from Marc Glisse ---
Author: glisse
Date: Mon Nov 3 10:47:04 2014
New Revision: 217034
URL: https://gcc.gnu.org/viewcvs?rev=217034&root=gcc&view=rev
Log:
2014-11-03 Marc Glisse
PR tree-optimization/60770
gcc/
* tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714
--- Comment #5 from Marc Glisse ---
https://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F
(and for selecting the shell: https://gcc.gnu.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63734
--- Comment #1 from Marc Glisse ---
My first impression is that this is a target issue, we should be able to call
TARGET_VECTORIZE_VEC_PERM_CONST_OK from gimple. Either the target should avoid
calling gen_reg_rtx when we are only calling the pred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738
Marc Glisse changed:
What|Removed |Added
Summary|[5 Regression] ssa |[4.9/5 Regression] ssa
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63753
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63774
--- Comment #3 from Marc Glisse ---
At least it was deliberate. I did wonder if anyone would complain when I wrote
the patch...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
--- Comment #2 from Marc Glisse ---
long long (or int64_t) is not part of C++03, so solaris headers don't provide
the overload. We complete the set of overloads in c* headers, but there is a
well known bug that we don't provide wrappers for the *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63803
--- Comment #6 from Marc Glisse ---
If dereferencing 0 is ok on your platform, you need at least
-fno-delete-null-pointer-checks. I don't know if the isolate pass checks that
flag though (it probably should).
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
wide-int.h contains code like:
template <>
template
struct binary_traits
{
typedef widest_int result_type;
};
g++ fails to warn about the extra parameter list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886
--- Comment #1 from Marc Glisse ---
warning: conversion to ‘int’ from ‘float’ may alter its value
[-Wfloat-conversion]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55039
--- Comment #7 from Marc Glisse ---
std::addressof can be constexpr with -std=gnu++XX, and even in strict mode
std::__addressof can be constexpr for internal use in libstdc++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #21 from Marc Glisse ---
Author: glisse
Date: Tue Nov 18 20:20:53 2014
New Revision: 217735
URL: https://gcc.gnu.org/viewcvs?rev=217735&root=gcc&view=rev
Log:
2014-11-18 Marc Glisse
PR libstdc++/43622
gcc/cp/
* rtti.c (em
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #22 from Marc Glisse ---
__float128 is still missing a specialization of numeric_limits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #11 from Marc Glisse ---
Author: glisse
Date: Sat Nov 22 14:28:19 2014
New Revision: 217967
URL: https://gcc.gnu.org/viewcvs?rev=217967&root=gcc&view=rev
Log:
2014-11-22 Marc Glisse
PR tree-optimization/60770
* tree-sra.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #18 from Marc Glisse ---
The .uninit dump for the original testcase now looks like:
double foo(A) (struct A a)
{
double SR.1;
:
return SR.1_2(D);
}
which the uninit pass would warn about, except that SR.1 is marked
TREE_NO_W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61528
--- Comment #8 from Marc Glisse ---
If I mark f as static or inline (so the optimizer changes f to take its
argument by value), I get with g++-5:
w2.c: In function 'int main()':
w2.c:11:7: warning: '' is used uninitialized in this function
[-Wun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031
--- Comment #1 from Marc Glisse ---
-ffast-math lets it vectorize (using min directly). Otherwise, for the first
test, ifcvt gives (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #7 from Marc Glisse ---
(In reply to Jan Hubicka from comment #0)
> It would be nice to use the fact that the default
> operator new throw exception instead of returning NULL in out of memory case.
Note that often you want to know no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
--- Comment #6 from Marc Glisse ---
LWG marked issue 2302 as pending NAD, but CWG was more helpful and we now have
an official DR so we can patch the front-end:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1748
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #1 from Marc Glisse ---
Uh? 100/1000==0, I don't understand your point.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Comparing a log file to itself fails. I already had to use compare_tests for
each sum file separately, since, when I enable all languages, trying to use it
on
ormal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
In the following code, on x86_64-unknown-linux-gnu, we should call g(0,8,16),
but we somehow end up calling g(0,16,16). The most suspicious dump is
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
--- Comment #2 from Marc Glisse ---
(In reply to Andrew Pinski from comment #1)
> Was this before or after revision 218658 ?
Exactly at 218658 (there were more failures before that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62207
--- Comment #2 from Marc Glisse ---
(In reply to Ville Voutilainen from comment #1)
> Current trunk doesn't ICE.
Yes it does. Is your compiler built with checking disabled?
$ g++ x.c
[many errors]
x.c:16:3: internal compiler error: tree check:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61670
Marc Glisse changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61670
--- Comment #4 from Marc Glisse ---
I checked 2 versions of the compiler, built with rather different options.
$ /tmp/gcc-trunk/inst/bin/g++ -v au.ii
Using built-in specs.
COLLECT_GCC=/tmp/gcc-trunk/inst/bin/g++
COLLECT_LTO_WRAPPER=/tmp/gcc-trun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64308
--- Comment #2 from Marc Glisse ---
You would need symbolic ranges, b and ret are in [0,m-1]. And then you are
using that very specific x86 instruction that divides 64 bits by 32 bits but
only works if the result fits in 32 bits. It works here be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64297
--- Comment #2 from Marc Glisse ---
struct A {
typedef int X;
template X m_fn1() const;
};
template struct is_function {};
is_function i;
struct D {
template > D(Y);
} b(&A::m_fn1<0>);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #6 from Marc Glisse ---
(In reply to Marek Polacek from comment #5)
> I don't think so. I tried to come up with a more general transformation
> that would simplify ((CST << n) & CST) != 0, but I haven't found anything
If both CST ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #11 from Marc Glisse ---
(In reply to Oleg Endo from comment #7)
> (1 << n) & 6 != 0 -> n > 0 && n < 3 (not beneficial)
We usually spell it (unsigned)n-1<2 (still not that great).
(In reply to Marek Polacek from comment #8)
> > > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64309
--- Comment #12 from Marc Glisse ---
(In reply to Marc Glisse from comment #11)
> ((pow2< p==n
Oups, it wasn't supposed to be the same power of 2, so:
(((1< p==n+(l-k)
(k and l are constants)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62191
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399
--- Comment #6 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #4)
> It might be valid with a custom deleter, but the example shown has undefined
> behaviour.
When the derived class does not add any member or redefine any importan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #1 from Marc Glisse ---
There are a number of things that make it complicated.
1) gcc doesn't like to vectorize when the number of iterations is not known at
compile time.
2) gcc doesn't vectorize anything already involving complex or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #3 from Marc Glisse ---
(In reply to Conrad from comment #2)
> (In reply to Marc Glisse from comment #1)
> > 3) the ABI for complex uses 2 separate double instead of a vector of 2
> > double.
>
> Technically yes, but in practice aren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #6 from Marc Glisse ---
(In reply to Marc Glisse from comment #5)
> The problem is during the TODO, in execute_update_addresses_taken, which
> finds out that q does not need its address taken anymore, and
>
> /* For v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #7 from Marc Glisse ---
Created attachment 33024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33024&action=edit
replace clobber with default def
This passes bootstrap+testsuite with all default languages, but it breaks ada,
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536
--- Comment #16 from Marc Glisse ---
I am now getting an abi_check failure on x86_64-linux-gnu on a -O0 -g build
because of this symbol. Is it expected?
1 incompatible symbols
0
_ZNKSt9type_infoeqERKS_
std::type_info::operator==(std::type_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
--- Comment #9 from Marc Glisse ---
The warnings are "normal", they also appear in a non-patched build, so that
leaves only the coalesce errors.
(In reply to Eric Botcazou from comment #8)
> The Ada front-end is the only serious user of abnormal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #21 from Marc Glisse ---
One argument against the sequence point is that we don't have one for ?: . If
we add one for ?: several testcases regress, so we have to make sure to only do
the save_expr/compound_expr thing if there are side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61655
--- Comment #1 from Marc Glisse ---
Try -fno-elide-constructors. Why would you want a copy? Is it because of the
parentheses in the return statement that you expect elision not to be
performed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61655
--- Comment #4 from Marc Glisse ---
Look up "copy elision" (the wikipedia article will do).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61660
--- Comment #6 from Marc Glisse ---
(In reply to Udo Steinberg from comment #5)
> Yes, I'm saying a similar warning should be emitted for x.
No it should not, you are using x and s in completely different ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #2)
> So perhaps teach fold also about A CMP B ? A - B : -(A - B) etc.?
Or teach phiopt about A CMP B ? (U)((T)A - (T)B) : (U)((T)B - (T)A)? Hmm, it is
starting to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747
--- Comment #1 from Marc Glisse ---
I think you need -fno-signed-zeros for the transformation to be valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747
--- Comment #3 from Marc Glisse ---
(In reply to vincenzo Innocente from comment #2)
> > I think you need -fno-signed-zeros for the transformation to be valid.
> possible.
> but then is the O2 code that is wrong?
> in any case adding -fno-signed-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #9 from Marc Glisse ---
(In reply to Paolo Carlini from comment #6)
> Marc, are you going to send your patch to the mailing list (CC Jason)?
Sorry, I don't remember this patch at all. I may try again to understand what
it does at som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551
--- Comment #14 from Marc Glisse ---
Author: glisse
Date: Sat Jul 26 09:00:31 2014
New Revision: 213076
URL: https://gcc.gnu.org/viewcvs?rev=213076&root=gcc&view=rev
Log:
2014-07-26 Marc Glisse
PR target/44551
gcc/
* simplify-rtx.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61077
--- Comment #3 from Marc Glisse ---
/* { dg-warning "qualified parameter type.*int" "parameter" { target *-*-* } 6
} */
Marek, could you use \[^\n\]* instead of .* please? The next dg-warning fails
if the name of the source directory contains "i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61077
--- Comment #6 from Marc Glisse ---
Thanks, that was fast :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938
--- Comment #4 from Marc Glisse ---
Please show what you would like the code to look like after vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
--- Comment #15 from Marc Glisse ---
Author: glisse
Date: Thu Jul 31 09:33:58 2014
New Revision: 213323
URL: https://gcc.gnu.org/viewcvs?rev=213323&root=gcc&view=rev
Log:
2014-07-31 Marc Glisse
PR c++/60517
gcc/c/
* c-typeck.c (c_fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #4 from Marc Glisse ---
(In reply to Avi Kivity from comment #3)
> I observed this with non-trivial destructors as well.
>
> In fact, something like:
>
> X::~X() { i = 3; }
>
> also emits a store.
Not for me, at least at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
Marc Glisse changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005
--- Comment #2 from Marc Glisse ---
Ah, I didn't test with --enable-ckecking=rtl.
We could split the "maybe" part of the warning and downgrade it to Wextra, but
I'd rather keep it at least in Wall, which means we need to change the
loop-unroll c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005
--- Comment #4 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #3)
> That said, an interesting question is why we don't warn about this without
> rtl checking, the function still returns address of the parameter. Is that
> because i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62005
--- Comment #5 from Marc Glisse ---
(In reply to Marc Glisse from comment #4)
> Compiling without RTL checking but with -fkeep-inline-functions
> probably warns as well then.
Uh, for some reason -fkeep-inline-functions does not preserve static f
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
std::prev forwards to advance without any concept checking, and advance then
doesn't mind if the iterator is a forward iterator. I have seen several posts
on stackoverflow where people compl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
--- Comment #2 from Marc Glisse ---
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html would most likely fix
it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
--- Comment #3 from Marc Glisse ---
(In reply to Marc Glisse from comment #2)
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01812.html would most likely
> fix it...
Ah, no, it doesn't:
_2 = { -0.0, -0.0, -0.0, -0.0 } - x_1(D);
doesn't get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
--- Comment #4 from Marc Glisse ---
(The gimple version works with -ffast-math at least)
In fold-const.c, fold_real_zero_addition_p has:
/* In a vector or complex, we would need to check the sign of all zeros. */
if (TREE_CODE (addend) !=
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
export CFLAGS=--coverage
export CXXFLAGS=--coverage
/path/to/configure --enable-languages=c,c++ --with-system-zlib --disable-nls
--disable-bootstrap
make -j 12
[...]
libtool: compile: /tmp/gcc-bug/build
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
extern void f () __attribute__ ((__noreturn__));
$ g++ -fcilkplus -c marc1.c
marc1.c:1:47: warning: '__noreturn__' attribute does not apply to types
[-Wattributes]
extern void f () __a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62047
Marc Glisse changed:
What|Removed |Added
Component|bootstrap |c++
--- Comment #1 from Marc Glisse ---
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62054
--- Comment #1 from Marc Glisse ---
Did you try it? It doesn't compute the same thing at all...
2201 - 2300 of 2562 matches
Mail list logo
