http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046
Bug ID: 59046
Summary: [4.8.x REGRESSION] corei7: L1 + L2 cache size not
correct
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Fri Nov 8 08:44:02 2013
New Revision: 204561
URL: http://gcc.gnu.org/viewcvs?rev=204561&root=gcc&view=rev
Log:
2013-11-08 Richard Biener
PR tree-optimization/59038
PR tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Fri Nov 8 08:44:02 2013
New Revision: 204561
URL: http://gcc.gnu.org/viewcvs?rev=204561&root=gcc&view=rev
Log:
2013-11-08 Richard Biener
PR tree-optimization/59038
PR tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #16 from Richard Biener ---
(In reply to H.J. Lu from comment #15)
> (In reply to Eric Botcazou from comment #14)
> > > This is good to hear. What is each field? I assume that
> > > the first 3 fields are frame address, resume addres
-gmp=/usr/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131108 (experimental) [trunk revision 204560] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
1
$ gcc-4.8.2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
Paolo Carlini changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #17 from H.J. Lu ---
(In reply to Richard Biener from comment #16)
> > I couldn't find anything in GCC manual.
>
> See tm.texi / md.texi.
This is the only thing I found:
-- Macro: DONT_USE_BUILTIN_SETJMP
Define this macro to 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59046
--- Comment #2 from H.J. Lu ---
(In reply to Marc Burkhardt from comment #0)
> According to a comment in #57657 this should have been fixed in May 15th,
The comment says it was INTRODUCED on May 15.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48110
--- Comment #2 from Richard Biener ---
Indeed, not sure why we even support "3" or "s", but "fast" would certainly
alias with -fast ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59038
Richard Biener changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59045
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #18 from Eric Botcazou ---
> I couldn't find anything in GCC manual.
There are a few documented hooks, but this looks quite light indeed, so the
sources are probably the best references, i.e. builtins.c and except.c:
/* __builtin_lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258
mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
Bug ID: 59048
Summary: std::string operator== between std::string and const
char* creates unecessary temporary object
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
--- Comment #6 from Eric Botcazou ---
> Always considering trap-if as ending a BB appears to be a bit of a rathole.
> Every time I squash one issue, another raises its head.
A little unexpected I'd say, what kind of issues does that introduce?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #2 from Jonathan Wakely ---
(In reply to Luca Stoppa from comment #0)
> Template functions
> bool operator==( const char*, const std::string& ) and
> bool operator==( const std::string&, const char* )
> creates unecessary temporary std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #3 from Luca Stoppa ---
Created attachment 31181
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31181&action=edit
testcase
g++ -O3 mapping.cpp
time ./a.out 1000 f
time ./a.out 1000 g
time ./a.out 1000 h
time ./a.out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #4 from Paolo Carlini ---
Indeed, I had a look to f and the correct operator== and compare are called, no
temporaries. By the way, type_traits uses memcmp not strcmp.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #5 from Luca Stoppa ---
Thanks a lot,
so if memcmp() is called, how can the difference in performance be explained?
In short:
std::string s="something";
if (s == "something") { ... }
and
if (0 == strcmp(s.c_str(),"something")) { ..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #6 from Paolo Carlini ---
An important detail is that the compare functions aren't inline, and are
exported for basic_string. Thus, for a fair comparison, the strcmp should
be in an attribute noinline helper (to be 100% correct, should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #7 from Jonathan Wakely ---
The only major difference I see is that in the operator== case you make a call
to a PIC function in libstdc++.so, whereas strcmp can be inlined.
There's no temporary created though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #8 from Paolo Carlini ---
Right, it's also PIC.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934
--- Comment #11 from Martin Jambor ---
I have re-submitted my patch in which this bug is fixed, you can find
it at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00598.html
I have verified the patch bootstraps on i686-linux (reported by Jakub
in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Fri Nov 8 12:49:10 2013
New Revision: 204566
URL: http://gcc.gnu.org/viewcvs?rev=204566&root=gcc&view=rev
Log:
2013-11-08 Richard Biener
PR tree-optimization/59047
* tree-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653
Bug 58653 depends on bug 59047, which changed state.
Bug 59047 Summary: [4.9 Regression] wrong code for bitfields at -O3 on
x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59047
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
Bug ID: 59049
Summary: Two VOIDmode constant in comparison passed to
cstoresi4
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
Bug ID: 59050
Summary: [4.9 Regression] ICE: tree check: expected
integer_cst, have nop_expr in tree_int_cst_lt, at
tree.c:7083
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051
Bug ID: 59051
Summary: DW_tag_restrict_type not used
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
octoploid at yandex dot com changed:
What|Removed |Added
CC||congh at google dot com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #9 from Luca Stoppa ---
Created attachment 31182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31182&action=edit
not inlined memcmp used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680
Jean-Pierre Flori changed:
What|Removed |Added
CC||jpflori at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
--- Comment #10 from Luca Stoppa ---
Hi,
honestly I don't know what PIC means, but I did like you suggested. I have
added a wrapper to memcmp() that is not inlined.
__attribute__((noinline)) int memcmp_not_inlined
(const char *s1, const char *s2,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58423
--- Comment #4 from clyon at gcc dot gnu.org ---
Author: clyon
Date: Fri Nov 8 14:22:10 2013
New Revision: 204570
URL: http://gcc.gnu.org/viewcvs?rev=204570&root=gcc&view=rev
Log:
gcc/
2013-11-05 Zhenqiang Chen
Backport from trunk r203267,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #2 from Tom De Caluwé ---
As far as I can verify partial specializations are only allowed at namespace
scope so you're right. However gcc never used to complain about such
constructs.
In any case, an internal compiler error is never d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #1 from Jorn Wolfgang Rennecke ---
Frame 12 shows that at the tree level, one of the comparison operands is an
initialized variable.
(gdb) frame 12
#12 0x083bd9fa in expand_expr_real_1 (exp=, target=0x0,
tmode=VOIDmode, modifier=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #3 from Paolo Carlini ---
Yes. It's all about prioritizing, an ICE on invalid isn't the same as an ICE on
valid, even if it's a regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #4 from Tom De Caluwé ---
However the following code seems to be valid but results in the same ICE:
/* bug.cpp --- */
namespace N {
template
class C {
private:
template
struct Implem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #5 from Paolo Carlini ---
Frankly, I'm not sure either, current clang rejects it the same way, for
example. In any case, in Bugzilla we have got at least 2/3 on valid Bugs
triggering that gcc_assert, hopefully will be fixed all togethe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #4 from Jack Howarth ---
Current llvm trunk is broken at the moment on darwin, but using a build from
Oct 29th, I have no issues with the failing test case under clang...
% /sw/opt/llvm-3.4/bin/clang -O1 -fsanitize=address -fno-builti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #5 from Jack Howarth ---
(In reply to Jack Howarth from comment #4)
This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #19 from H.J. Lu ---
(In reply to Eric Botcazou from comment #18)
> > I couldn't find anything in GCC manual.
>
> There are a few documented hooks, but this looks quite light indeed, so the
> sources are probably the best references,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #3 from Jorn Wolfgang Rennecke ---
Making emit_store_flag return 0 in the case of const-const comparison
gives simpler rtl generation:
(insn 14 13 15 (set (reg:QI 175)
(const_int 1 [0x1])) .../strlen-2.c:29 -1
(nil))
(in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052
Bug ID: 59052
Summary: Partial specialization of template with dependent
non-type template argument not correctly resolved
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
--- Comment #6 from Tom De Caluwé ---
I reported a related bug with valid code which does not trigger this ICE (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59052).
Also LLVM bug 16519 (http://llvm.org/bugs/show_bug.cgi?id=16519) might be
rela
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
Bug ID: 59053
Summary: cilkplus branch compiler loops
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #20 from Eric Botcazou ---
> Would it be OK to submit it a patch to document
> __builtin_longjmp/__builtin_setjmp based on their
> sources?
I think that we would need to issue an error if both are in the same function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
--- Comment #8 from congh at gcc dot gnu.org ---
Author: congh
Date: Fri Nov 8 18:44:46 2013
New Revision: 204590
URL: http://gcc.gnu.org/viewcvs?rev=204590&root=gcc&view=rev
Log:
2013-11-08 Cong Hou
PR tree-optimization/58508
* gcc.d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58963
--- Comment #1 from Cong Hou ---
Any comment on this topic?
thanks,
Cong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #21 from Andreas Schwab ---
It's only an error if they use the same jmpbuf.
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=56717
Cong Hou changed:
What|Removed |Added
CC||congh at google dot com
--- Comment #1 from Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680
--- Comment #4 from gee ---
I think gcc backend for x86 that doesn't support weak attribute needed to
supress weak attribute on variables as long as gas/16011 is not fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054
Bug ID: 59054
Summary: Powerpc -O0 -mcpu=power7 generates sub-optimal code to
load 0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #22 from bviyer at gcc dot gnu.org ---
Author: bviyer
Date: Fri Nov 8 19:52:27 2013
New Revision: 204592
URL: http://gcc.gnu.org/viewcvs?rev=204592&root=gcc&view=rev
Log:
+2013-11-08 Balaji V. Iyer
+
+ PR c/59039
+ * ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054
--- Comment #1 from Michael Meissner ---
Created attachment 31185
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31185&action=edit
Sample file to show the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
--- Comment #4 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #2)
> I think at least something like this for this specific bug, but the whole
> file needs auditing:
Not only that file, but stl_algobase.h too, we compile this wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
--- Comment #5 from Jonathan Wakely ---
And this, which is more obviously wrong:
std::atomic a[1];
std::atomic b[1];
std::copy(a,a+1, b);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
--- Comment #6 from Paolo Carlini ---
At some point we replaced a weak (not using front-end intrinsics) version of
is_pod with __is_trivial, in algos & uninitialized. At that time was safe,
ins't anymore in 4.9. In principle we could minimally go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055
Bug ID: 59055
Summary: gcc.texinfo warnings
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
--- Comment #7 from Jonathan Wakely ---
Yes, it's not too hard to fix properly, so I'm working on that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
--- Comment #23 from H.J. Lu ---
Created attachment 31186
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31186&action=edit
A patch to document __builtin_setjmp/__builtin_longjmp
Does it look OK?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
--- Comment #8 from Paolo Carlini ---
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59053
--- Comment #2 from John Forrest ---
Thanks for your very fast response. Glad it was easy to reproduce.
John Forrest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Nov 8 22:16:59 2013
New Revision: 204604
URL: http://gcc.gnu.org/viewcvs?rev=204604&root=gcc&view=rev
Log:
Move Cilk Plus Builtins node before Other Builtins node
PR other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
Bug ID: 59056
Summary: enable_if turns a non-ambiguous template into an
ambiguous one
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #1 from Paolo Carlini ---
Needs an analysis, but I doubt this is a bug, all the up to date compilers I
have handy (eg, clang, icc) reject it the same way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58998
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56717
--- Comment #2 from Cong Hou ---
I examined the GCC generated code, and found the main problem is that the load
of 'scale' (rhs operand of >>) to an xmm register is in the loop body, which
could be moved outside.
This happened during rtl-reload p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59057
Bug ID: 59057
Summary: bootstrap comparison failure with
-frecord-gcc-switches
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priorit
/local/gcc-trunk
--with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk
--with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20131108 (experimental) [trunk revision 204593] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
-1
$ gcc-trunk -O3 small.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640
--- Comment #12 from Jeffrey A. Law ---
Oleg, I just worked through an independent problem that I saw locally that
probably explains your SH issue as well. I expect to have a fix in the trunk
shortly. I'll let you know so you can test it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59059
Bug ID: 59059
Summary: [4.9 Regression] internal compiler error: tree check:
expected integer_cst, have nop_expr in
tree_int_cst_lt, at tree.c:6931
Product: gcc
Ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060
Bug ID: 59060
Summary: Accepts invalid ? Missing component data value for
component "D1" of TYPE("T2")
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
89 matches
Mail list logo
