Thanks to all my issue got resolved.
I placed the code in 'if block' checking cfun is NULL or not and
removed gcc_assert. It worked fine for me.
My idea is to print the lines of source code gcc is compiling. Further
to that I want to update the statement with
statement ; print(%s %d\n,
Hi Prakash,
statement ; print(%s %d\n, __FILE__, __LINE__);
So that when program is running I know which file which line of my program
is getting executed.
Just curious to know. Is there any real world application/product where this
will help? Can you give more context to this requirement.
Regarding requirement - yes. I believe that it would be a powerful
debugging tool to develop. It would be so powerful for analyzing code
flow of flows for very large projects - that an ordinary developer can
understand code in minutes. Say I have 100,000,00 Lines of code.
Debugging using GDB or
On Tue, Jun 12, 2012 at 8:34 AM, Satya Prakash Prasad
satyaprakash.pra...@gmail.com wrote:
Thanks to all my issue got resolved.
I placed the code in 'if block' checking cfun is NULL or not and
removed gcc_assert. It worked fine for me.
My idea is to print the lines of source code gcc is
On Tue, 12 Jun 2012, Bin.Cheng wrote:
I noticed that GCC now can check format string of printf functions, so
I am wondering if it is possible to take advantage of this utility, by
making gcc detect whether printf prints floating point number and then
generate assembly directive in backend
On 11/06/2012 21:20, t-rexky wrote:
#includemath.h
#includestdio.h
int main() {
printf(%lf\n, acos(0.5));
return 0;
}
First, note that acos(0.5) is a double expression so its format should
be %f. However %lf is tolerated and this should not cause any trouble.
Second, the acos() call
Joseph S. Myers wrote:
On Tue, 12 Jun 2012, Bin.Cheng wrote:
I noticed that GCC now can check format string of printf functions, so
I am wondering if it is possible to take advantage of this utility, by
making gcc detect whether printf prints floating point number and then
generate assembly
On 06/11/2012 07:20 PM, Joel Brobecker wrote:
From the ChangeLog entry, it seems like Pedro was involved in the making
of that patch, so perhaps he could be a good reviewer?
All involvement I recall was updating a couple lines to
new interfaces in the context of a merge from upstream. All
Our front end is wierd.
The input is unusually low level, and so are the trees it produces.
I do have a hankering to fix that (or maybe just to output more portable C...)
But for now:
It doesn't use component_refs, and doesn't
define types much, but uses either
either (type*)(base + offset) or
Hi,
On Tue, Jun 12, 2012 at 03:57:44PM +, Jay K wrote:
Our front end is wierd.
The input is unusually low level, and so are the trees it produces.
I do have a hankering to fix that (or maybe just to output more portable C...)
But for now:
It doesn't use component_refs, and doesn't
On Tue, Jun 12, 2012 at 03:57:44PM +, Jay K wrote:
Our front end is wierd.
The input is unusually low level, and so are the trees it produces.
I do have a hankering to fix that (or maybe just to output more portable
C...)
But for now:
It doesn't use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53641
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #7 from chrbr at gcc dot gnu.org 2012-06-12 06:25:09 UTC ---
(In reply to comment #6)
I thought that -pg and -fomit-frame-pointer are always incompatible.
Agree with the possible issues for old unwinders.
I've forgotten that sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
06:27:42 UTC ---
As I said, there's a simple workaround.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-12
07:09:58 UTC ---
Author: olegendo
Date: Tue Jun 12 07:09:52 2012
New Revision: 188426
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188426
Log:
PR target/50749
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-12
07:40:26 UTC ---
Created attachment 27606
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27606
gcc48-pr53639.patch
The first problem is that combiner combines:
(insn 9 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-12
07:52:53 UTC ---
Author: jakub
Date: Tue Jun 12 07:52:47 2012
New Revision: 188428
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188428
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642
Bug #: 53642
Summary: Front-end optimization: Wrong string length for
deferred-length strings
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
Bug #: 53643
Summary: [OOP] ICE (segfault) with INTENT(OUT) CLASS array
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #4 from Conrad conradsand.arma at gmail dot com 2012-06-12
08:59:54 UTC ---
Created attachment 27607
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27607
pre-processed source exposing the bug
bug confirmed on Fedora 17, using gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50569
--- Comment #16 from Jiangning Liu liujiangning at gcc dot gnu.org 2012-06-12
09:24:21 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:24:11 2012
New Revision: 188431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188431
Log:
2011-06-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53640
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #6 from Conrad conradsand.arma at gmail dot com 2012-06-12
09:42:08 UTC ---
bug not present when compiling with Clang 3.0
(I've found clang to often have more thorough/readable diagnostics than gcc)
output of clang -v:
clang version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51070
--- Comment #10 from Jiangning Liu liujiangning at gcc dot gnu.org 2012-06-12
09:44:28 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:44:24 2012
New Revision: 188432
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188432
Log:
2011-06-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51042
--- Comment #9 from Jiangning Liu liujiangning at gcc dot gnu.org 2012-06-12
09:53:57 UTC ---
Author: liujiangning
Date: Tue Jun 12 09:53:53 2012
New Revision: 188433
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188433
Log:
2011-06-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-12
10:11:51 UTC ---
Btw, when I run the benchmark with the addition of -march=native (for me,
that's
-march=corei7) then GCC 4.7 performs better than 4.6:
4.6:
./t 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-12
10:27:15 UTC ---
Small testcase:
int a[256];
int b[256];
void foo (void)
{
int i;
for (i = 0; i 256; ++i)
{
b[i] = a[i] * 23;
}
}
you can see that we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||fabien at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-12
10:39:19 UTC ---
And cprop fails to propagate
(reg:V4SI 85) := (const_vector:V4SI [
(const_int 23 [0x17])
(const_int 23 [0x17])
(const_int 23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
10:39:20 UTC ---
Further reduced, a single example showing both errors:
templatetypename T
struct C
{
int operator()();
templateint I
struct F : C
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Attachment #27606|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53604
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||paul.scruby
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
10:47:58 UTC ---
I think it compiles with 4.4 because __cook::~__cook is not noexcept, because
4.4 doesn't infer an empty throw spec for a trivial destructor.
If you add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||stevenb.gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-12
12:17:37 UTC ---
This started to be rejected with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=182711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53639
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-06-12 12:21:07
UTC ---
(In reply to comment #2)
Unfortunately that patch regressed pr49095.c testcase. So, either we limit
the
splitter to the paradoxical subreg that is created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53643
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-12
12:33:34 UTC ---
I am not sure whether the following (in trans-decl.c) is the proper fix or an
ugly work around, but it seems to work. -- Maybe, a proper fix would be to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Bug #: 53644
Summary: ICE in force_move_args_size_note, at
combine-stack-adj.c:419
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Bug #: 53645
Summary: Missed optimization for division of vector types
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
--- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-06-12 13:03:57
UTC ---
Created attachment 27610
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27610
alt.src for 416.games
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Bug #: 53646
Summary: Surprising effects of cxx11 vs cxx98 ABI compatibility
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #8 from chrbr at gcc dot gnu.org 2012-06-12 13:26:42 UTC ---
Created attachment 27612
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27612
fix
All the suspicious flags reviewed and looked OK excepted maybe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
13:38:01 UTC ---
(In reply to comment #0)
In this specific case the problem is the Rb_tree::equal_range function,
which returns a pair, under cxx98 that's POD (returned via
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53644
Matthias Klose doko at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53602
Matthias Klose doko at gcc dot gnu.org changed:
What|Removed |Added
CC||doko at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-12
13:56:37 UTC ---
The patch is pre-approved. Thanks for looking into the issue
thoroughly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-12
14:06:18 UTC ---
Ok, that doesn't apply for me (I'm stuck on v1.0). I can reproduce it with
-fno-tree-vrp without LTO but only with reference input (thus bisecting
to a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
14:19:33 UTC ---
N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
could have done to cause the FE to change how it returns a std::pair.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
14:27:58 UTC ---
I don't think this is a libstdc++ issue, precompiling the code with 4.7 and
then compiling with 4.8 still segfaults, so it's a FE change not a libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
14:29:03 UTC ---
(In reply to comment #3)
I don't think this is a libstdc++ issue, precompiling ...
Sorry, brainfart, I meant preprocessing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
--- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-06-12
15:01:31 UTC ---
Author: jason
Date: Tue Jun 12 15:01:17 2012
New Revision: 188460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188460
Log:
PR c++/53599
Revert:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
--- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2012-06-12
15:01:29 UTC ---
Author: jason
Date: Tue Jun 12 15:01:17 2012
New Revision: 188460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188460
Log:
PR c++/53599
Revert:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.7.1 |4.7.2
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 2012-06-12 15:36:01
UTC ---
(In reply to comment #2)
N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
could have done to cause the FE to change how it returns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2012-06-12 15:41:49
UTC ---
FWIW, it's finish_struct_bits setting TREE_ADDRESSABLE, because
type_has_nontrivial_copy_init returns true for pair with that ctor.
I think this indeed makes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
Bug #: 53647
Summary: [4.8 Regression] gcc.c-torture/compile/20011229-1.c
and gcc.c-torture/compile/pr25311.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
15:50:05 UTC ---
Trivially copyable is just one small part of the POD requirements. std::pair
has always been non-POD, even in c++98, but in c++98 it is trivially copyable,
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||paolo.carlini at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
15:57:16 UTC ---
Defaulting that move-ctor fixes the issue referred to in comment 1 too.
I think we need to find out if that comment is still relevant and fix it if it
is, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2012-06-12 16:02:28
UTC ---
Yep, defaulting that ctor changes the ABI back to register passing.
If we could change that in libstdc++, all the better, but I still think the
issue is larger
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-12
16:04:58 UTC ---
Daniel should have all the details. It might be possible to do the change
*together* with changing the constraining in the various container::insert to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-12
16:12:55 UTC ---
If I remember correctly, the last time I tried, default + is_constructible
worked pretty well modulo testcases sensitive to access control under
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Bug #: 53648
Summary: nested empty tuple
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #2 from chesstr at hotmail dot com 2012-06-12 17:13:33 UTC ---
(In reply to comment #1)
I have a fix for this already, IIRC it's simply a case of not using the EBO
for
a tuple that contains std::tuple
Yes, an easy fix in tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-12
17:27:50 UTC ---
There are other cases involving non-empty tuples that will still result in an
ambiguity e.g.
struct A { };
auto d = tupletupletupleA, A, A, A{};
My solution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-06-12 17:45:40
UTC ---
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -fno-diagnostics-show-caret
-Os -w -c -o pr25311.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53648
--- Comment #4 from chesstr at hotmail dot com 2012-06-12 18:03:56 UTC ---
(In reply to comment #3)
There are other cases involving non-empty tuples that will still result in an
ambiguity e.g.
struct A { };
auto d = tupletupletupleA, A, A,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-12
18:25:46 UTC ---
Author: olegendo
Date: Tue Jun 12 18:25:40 2012
New Revision: 188471
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188471
Log:
PR target/53511
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #11 from Matt Hargett matt at use dot net 2012-06-12 18:25:25 UTC
---
Richard,
Thanks for the quick analysis! Sounds like a perfect storm of sorts :/
re: cprop failure: this may be indicated by another major regression in their
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53599
--- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2012-06-12
18:32:10 UTC ---
Author: jason
Date: Tue Jun 12 18:32:04 2012
New Revision: 188473
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188473
Log:
PR c++/53599
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #12 from Richard Henderson rth at gcc dot gnu.org 2012-06-12
18:54:24 UTC ---
(In reply to comment #10)
But maybe allowing const_vector in (some of) the define_insn_and_split would
be the way to go ...
Maybe. It certainly would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Component|middle-end |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-06-12
19:09:48 UTC ---
If this is incorrect, and zero is supposed to indicate a cacheless memory (do
they exist anymore?), then I can disable the adjacent-loads hoisting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-06-12 19:26:12
UTC ---
We should update i386.c to have reasonable values for
size of l1 cache, size of l2 cache, size of prefetch block
and number of parallel prefetches, instead of 0s.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-06-12 19:40:21
UTC ---
Perhaps simply:
--cut here--
Index: tree-ssa-phiopt.c
===
--- tree-ssa-phiopt.c (revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-06-12 19:45:56
UTC ---
Alternative patch with the same functionality:
--cut here--
Index: tree-ssa-phiopt.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-06-12 19:45:56
UTC ---
Alternative patch with the same functionality:
--cut here--
Index: tree-ssa-phiopt.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17958
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|roger at eyesopen dot com |dtemirbulatov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53645
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Depends on||51581
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53196
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-12
21:16:24 UTC ---
Author: jakub
Date: Tue Jun 12 21:16:20 2012
New Revision: 188483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188483
Log:
PR c/53532
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51034
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-12
21:16:24 UTC ---
Author: jakub
Date: Tue Jun 12 21:16:20 2012
New Revision: 188483
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188483
Log:
PR c/53532
PR
1 - 100 of 200 matches
Mail list logo