https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
--- Comment #10 from Marc Glisse ---
Manuel, you seem to want a -Wsuper-extra that you can use everyday (maybe with
a couple -Wno-*). What some other people want with -Weverything is a way to
discover what warnings are available in the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65881
--- Comment #1 from Marc Glisse ---
(In reply to Shawn Landden from comment #0)
> gcc on x86_64 recognizes __uint128_t, but this is not documented along with
> __int128, also there is no warning when a target does not support
> __uint128_t, like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65883
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65883
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Tue Apr 28 19:35:49 2015
New Revision: 222540
URL: https://gcc.gnu.org/viewcvs?rev=222540&root=gcc&view=rev
Log:
2015-04-28 Marc Glisse
PR libstdc++/65883
* include/std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65883
Marc Glisse changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65928
--- Comment #1 from Marc Glisse ---
It seems normal to me. There are now several functions called isblank in
namespace std, and the compiler doesn't know which one to pick when you don't
give it a hint (like you do for myblank). A more explicit d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #9 from Marc Glisse ---
VRP could still do better:
typedef unsigned short T;
T f(T x, T y){
// Avoid narrowing in the front-end
int ix=x;
int iy=y;
T z=ix%iy;
int iz=z;
return z%iy;
}
ix and iy both have range [0, 65535]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65641
--- Comment #4 from Marc Glisse ---
Currently, the only implemented policy uses primes from a hard-coded list for
the number of buckets. This makes it easy to precompute (and hard-code in the
library) anything that may be helpful to speed-up modu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65988
--- Comment #1 from Marc Glisse ---
Yes, there is (was?) a bug in ISL where they are missing extern "C" in
isl/val_gmp.h, which was hacked around in a buggy way in
graphite-isl-ast-to-gimple.c by including that file inside extern "C". I think
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66064
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66084
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #10 from Marc Glisse ---
Author: glisse
Date: Sat May 9 15:40:05 2015
New Revision: 222970
URL: https://gcc.gnu.org/viewcvs?rev=222970&root=gcc&view=rev
Log:
2015-05-09 Marc Glisse
PR tree-optimization/64454
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #11 from Marc Glisse ---
Author: glisse
Date: Fri May 15 17:34:15 2015
New Revision: 223221
URL: https://gcc.gnu.org/viewcvs?rev=223221&root=gcc&view=rev
Log:
2015-05-15 Marc Glisse
PR tree-optimization/64454
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #14 from Marc Glisse ---
(In reply to Andrew Pinski from comment #13)
> It might also be useful if the range is [0,10] for x%5 to be simplified down
> to just "t = x-5; x>=5?t:x;"
(I assume you meant [0,9])
I agree, but the profitabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66247
--- Comment #5 from Marc Glisse ---
(In reply to Matthew L. Martin from comment #3)
> The source code in question is downloaded as a prerequisite for building
> gcc-5.1.0 (gmp).
>
> Where should I file a bug against the test?
Assuming you are u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
--- Comment #8 from Marc Glisse ---
Author: glisse
Date: Fri May 22 21:05:26 2015
New Revision: 223591
URL: https://gcc.gnu.org/viewcvs?rev=223591&root=gcc&view=rev
Log:
2015-05-22 Marc Glisse
PR tree-optimization/63387
gcc/
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
In the example below, if p and q refer to different objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66270
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66302
--- Comment #3 from Marc Glisse ---
> Does it make sense?
So you expect the random generator for float to throw away half of the random
bits it is getting from the engine, just for this questionable benefit? And
actually 75%, so it matches with
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
int f(int a, int b, int c){
return a * b + a * c;
}
int main(){
return f(0, __INT_MAX__, __INT_MAX__);
}
$ gcc -fsanitize=undefined e.c
$ ./a.out
e.c:2:16: runtime error: signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66316
--- Comment #1 from Marc Glisse ---
(In reply to Alexander Trufanov from comment #0)
> Application has two .cpp modules. Let's say 1.cpp and 2.cpp.
> In each module there is a definition of struct N. Name N is the same for
> both. So we have two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66346
Marc Glisse changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Marc Glisse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59190
--- Comment #1 from Marc Glisse ---
A first step could be to teach alias analysis about BUILT_IN_ATOMIC_*,
currently it thinks i escapes in __atomic_add_fetch_4 (&i._M_i, 1, 5).
Unrelated, but maybe those builtins could also get the nonnull attrib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
Marc Glisse changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Version|4.4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59740
--- Comment #2 from Marc Glisse ---
PR58501 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59742
Marc Glisse changed:
What|Removed |Added
Severity|major |normal
--- Comment #2 from Marc Glisse ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873
--- Comment #4 from Marc Glisse ---
Seems to be on purpose, see the comment before _cpp_valid_ucn in
libcpp/charset.c, and the last instruction in that function.
[lex.charset] is a bit hard to read for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
--- Comment #5 from Marc Glisse ---
(In reply to Chengnian Sun from comment #4)
> I realize that the options "-Wall -Wextra" do not enable all the warnings.
> Is there a flag in GCC which enables all the available warning types,
> similar to -Weve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875
--- Comment #3 from Marc Glisse ---
(In reply to josephlawrie from comment #2)
> (In reply to Marc Glisse from comment #1)
> Am I correct in understanding this would not be possible without -fno-weak
> or when linking dynamically? In those cases,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172
Marc Glisse changed:
What|Removed |Added
CC||leonid at volnitsky dot com
--- Comment #8
||glisse at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Marc Glisse ---
Already fixed on trunk.
*** This bug has been marked as a duplicate of bug 57172 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779
--- Comment #16 from Marc Glisse ---
>AC_SEARCH_LIBS(gettext, intl, [], USE_NLS=no)
seems a bit crude, as it results in this link test:
#ifdef __cplusplus
extern "C"
#endif
char gettext ();
int
main ()
{
return gettext ();
;
return 0;
}
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
LTO is not really a brand new, experimental and exotic option anymore. I
believe that by default, on systems that support it, we should build the static
target
++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
operator new and operator delete are hidden in libsupc++ so they can be easily
replaced, either directly in the code, or later by interposing a library. Doing
so has a cost, and I have seen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59894
--- Comment #2 from Marc Glisse ---
(In reply to Markus Trippelsdorf from comment #1)
> Isn't inlining forbidden by the standard?
Yes (sorry, I mentioned that in PR 59875 and forgot to repeat it here), but
since this is a specific option where th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #2 from Marc Glisse ---
(In reply to jos...@codesourcery.com from comment #1)
> Are LTO objects now independent of the compiler host (see bug 41526) (so
> that such libraries will work properly when copied from one host to
> another
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #15 from Marc Glisse ---
Another example: http://stackoverflow.com/q/21253690/1918193
where we have (-DVERSION=2):
_128 = img$_M_impl$_M_start_130 + 400;
pretmp_146 = (long intD.12) _128;
pretmp_145 = (long intD.12) img$_M_i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #4 from Marc Glisse ---
Joseph, thank you for those precisions, I hadn't realized the width of the
problem. Similarly, on my Debian multiarch machine, when I cross-compile for
arm, I use a libgcc.a that was built natively on arm, so th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43538
Marc Glisse changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #10 from Marc Glisse ---
vector() _GLIBCXX_NOEXCEPT : _Base() { }
list() _GLIBCXX_NOEXCEPT
I think that's wrong, the default construction of the allocator may throw,
hence the conditional noexcept I was suggesting in com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59472
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
--- Comment #5 from Marc Glisse ---
(In reply to Marc Glisse from comment #0)
> It may be as easy as adding the flags to C(XX)FLAGS_FOR_TARGET
With a trivial fix for PR 43538, this works. However, we then hit PR 59472.
Also, if instead of gold 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #14 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #13)
> On trunk now we have separate (non-explicit) default constructors for deque,
> list, vector, map, multimap, set and multiset.
Thanks!
> Debug and profile modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898
--- Comment #4 from Marc Glisse ---
Here is a link to what the future (C++17) might look like for alignment:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918
--- Comment #4 from Marc Glisse ---
(In reply to Markus Trippelsdorf from comment #2)
> A bit further reduced:
I want to play! ;-)
struct E {
~E();
virtual void f() const;
};
struct B : E {};
struct G : virtual B {};
struct A {
virtual ~A(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
--- Comment #8 from Marc Glisse ---
I think Andrew's point is that we might have:
#if T_IS_UNSIGNED
typedef unsigned T;
#else
typedef int T;
#endif
int f(T,T);
and thus the following:
T_IS_UNSIGNED || f(a,b)
can be used as a short version f
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
#include
inline int f(int i){return i-1;}
int m(){
std::function h=f;
return h(1);
}
clang manages to optimize this to just:
int m(){return 0;}
However, g++ is stuck with a much
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59948
--- Comment #1 from Marc Glisse ---
(In reply to Marc Glisse from comment #0)
> if (f != 0B)
> // Shouldn't we know that f!=0? It is defined just above.
This happens because the test in fold-const.c is:
return !VAR_OR_FUNCTION_DECL_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333
--- Comment #26 from Marc Glisse ---
(In reply to Sergey from comment #23)
> cc -V:
> cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
That thing belongs in a museum.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
void f(unsigned p,unsigned q){
if(p>=q) throw 42;
if(p>=q) throw 33;
}
VRP fails to eliminate the redundant comparison, only DOM mana
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #24 from Marc Glisse ---
Thank you.
Sadly, for the example in comment #15, this is not quite enough, I need to add
forwprop+ccp right before the VRP1 pass (and then the range check is
eliminated, the vectorizer works and perfs are the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59100
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #26 from Marc Glisse ---
(In reply to Richard Biener from comment #25)
> VERSION=0 and VERSION=1 are the same speed for me now,
They aren't quite for me (2.5 vs 2.7) but
> VERSION=2 is a lot slower still.
that's the part I am concer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53017
--- Comment #2 from Marc Glisse ---
Author: glisse
Date: Mon Feb 3 19:07:55 2014
New Revision: 207436
URL: http://gcc.gnu.org/viewcvs?rev=207436&root=gcc&view=rev
Log:
2014-02-03 Marc Glisse
PR c++/53017
PR c++/59211
gcc/c-family/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
--- Comment #5 from Marc Glisse ---
Author: glisse
Date: Mon Feb 3 19:07:55 2014
New Revision: 207436
URL: http://gcc.gnu.org/viewcvs?rev=207436&root=gcc&view=rev
Log:
2014-02-03 Marc Glisse
PR c++/53017
PR c++/59211
gcc/c-family/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53017
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60089
--- Comment #3 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> You'd need to disable complex lowering at the GIMPLE level and see what
> support is missing from RTL expansion for example.
>
> For the disabling I'd suggest addi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092
--- Comment #4 from Marc Glisse ---
Hack: when the return value of posix_memalign is ignored, if the platform
supports it, replace with a call to aligned_alloc (C11), which has an easier
interface.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113
--- Comment #1 from Marc Glisse ---
(In reply to lmat from comment #0)
> Attached is the output from command line along with the
> preprocessed code that I was trying to compile.
Looks like you forgot to attach it?
> Please let me know if I can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
Marc Glisse changed:
What|Removed |Added
Target||i386-linux-gnu
Status|UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
--- Comment #5 from Marc Glisse ---
Created attachment 32088
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32088&action=edit
asm that prints 0
Strange, I can reproduce it easily with r207643 on Debian testing:
stedding /tmp $ /tmp/gcc-mult
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
--- Comment #8 from Marc Glisse ---
Er, right, my attachment is useless, it is the same as Uros' (but I can't see
how to remove it). If it matters:
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.24
GNU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
--- Comment #9 from Marc Glisse ---
Extract from a gdb session, showing 2 wrong branches taken:
(gdb) p f
$15 = 1
(gdb) step
15 j = k * 54;
(gdb)
16 g = j * 147;
(gdb)
18 if (d)
(gdb) p d
$16 = 1
(gdb) step
21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
Marc Glisse changed:
What|Removed |Added
Attachment #32088|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113
Marc Glisse changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #4 from Marc Glisse ---
Can this be closed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
--- Comment #1 from Marc Glisse ---
Note the related: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01480.html (PR
43538) and PR 59893.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #9 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #8)
> The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
>
> -Wmaybe-uninitialized
> For an automatic variable, if there exists a path fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #13 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
> GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213
--- Comment #4 from Marc Glisse ---
(In reply to hubert.vansteenhuyse from comment #3)
> Of course it is, the example is merely a pseudo code to make clear what
> happened.
That's my point, pseudo-code is useless, if we can't reproduce the issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60225
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60227
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60226
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #3 from Marc Glisse ---
(In reply to N Schaeffer from comment #2)
> Do you have a suggestion concerning my last question:
> How can I check if x is NaN in a portable way (not presuming any compilation
> option) ?
This should bypass so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60237
--- Comment #7 from Marc Glisse ---
(In reply to N Schaeffer from comment #6)
> Is there somewhere a rationale for not making isnan() find NaN's with
> -ffinite-math-only ?
finite-math-only is basically a promise that isinf and isnan always retur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #1 from Marc Glisse ---
In my opinion, the sensible thing to do is add constexpr to max_element (and
the __ops helpers) once the front-end supports it, not duplicate the code in
max(initializer_list). Well, since max_element is just on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60271
--- Comment #4 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #2)
> The same thought occurred to me, but I didn't file an issue.
Should I do it, or are you going to?
(In reply to Jonathan Wakely from comment #3)
> It's certainly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60308
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60308
--- Comment #2 from Marc Glisse ---
Seems to be my fault in r202781:
_Deque_base(const allocator_type& __a)
: _M_impl(__a)
- { }
+ { _M_initialize_map(0); }
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60308
--- Comment #3 from Marc Glisse ---
I guess this should take us back to how it worked in 4.8:
--- stl_deque.h(revision 207837)
+++ stl_deque.h(working copy)
@@ -467,7 +467,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_Deque_base(const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60226
Marc Glisse changed:
What|Removed |Added
CC||mikulas at artax dot
karlin.mff.cu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60310
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60313
--- Comment #1 from Marc Glisse ---
Dup of PR 50677 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60308
--- Comment #4 from Marc Glisse ---
Author: glisse
Date: Sat Feb 22 10:24:11 2014
New Revision: 208041
URL: http://gcc.gnu.org/viewcvs?rev=208041&root=gcc&view=rev
Log:
2014-02-22 Marc Glisse
PR libstdc++/60308
* include/bits/stl_dequ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #14 from Marc Glisse ---
Author: glisse
Date: Sat Feb 22 10:24:11 2014
New Revision: 208041
URL: http://gcc.gnu.org/viewcvs?rev=208041&root=gcc&view=rev
Log:
2014-02-22 Marc Glisse
PR libstdc++/60308
* include/bits/stl_deq
||glisse at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Marc Glisse ---
Fixed. Sorry for the break and thanks for the report.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #13 from Marc Glisse ---
(In reply to Richard Biener from comment #12)
> Yes, the fact that the return value p cannot be equal to q inside the
> function is not exposable.
Richard fixed this in PR 50262, yay!
So this PR is worth worki
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
I think it would be nice if g++ realized that static variables that have been
initialized don't later on become uninitialized again. A simple example:
extern int e;
static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Marc Glisse changed:
What|Removed |Added
Attachment #30981|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59894
--- Comment #4 from Marc Glisse ---
(In reply to Marc Glisse from comment #0)
> PR 59893 considers a different path using LTO to inline at link time the
> definition from libsupc++.
Note that doing both at the same time:
1) provide an inline vers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
Marc Glisse changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comment
2001 - 2100 of 2562 matches
Mail list logo
