https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl ---
(In reply to Jan Hubicka from comment #22)
> > > Doing it at same approximately the same place as loop header copying
> > > seems to
> > > make most sense to me. It benefits from early cleanups and DCE definitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #19 from davidxl ---
(In reply to Jan Hubicka from comment #18)
> > WE can try some internal benchmarks with this change too.
>
> That would be very welcome. Tracer used to be quite useful pass in old days,
> doing 1.6% on -O3+FDO S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #17 from davidxl ---
(In reply to Jan Hubicka from comment #16)
> I have moved tracer before the late cleanups that seems to be rather obbious
> thing to do. This lets us to optimize the testcase (with -O2):
> int main() ()
> {
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
davidxl changed:
What|Removed |Added
CC||xur at google dot com
--- Comment #8 from davi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220
--- Comment #2 from davidxl ---
(In reply to Richard Biener from comment #1)
> First of all you should mark the functions 'inline' as well.
This does not help.
Then the issue
> is that 'eq' is called indirectly which isn't allowed for always_
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Created attachment 33466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33466&action=edit
test case
Compile the attached source with -std=gnu++11 -O1 option, the compilation wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209
davidxl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Created attachment 33460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33460&action=edit
patch file
GCC (arm-unknown-linux-gnueabi) generates wrong code (O2) for the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
--- Comment #1 from davidxl ---
Created attachment 33264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33264&action=edit
test case
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Compile the attached source file with option -Os -g using aarch64 compiler,
the compiler ICEs:
et2.c: In function 'foo&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #7 from davidxl ---
(In reply to wmi from comment #6)
> (In reply to davidxl from comment #5)
> > (In reply to wmi from comment #4)
> > > Can we move the pure/const resetting loop to an earlier place: inside
> > > branch_prob , after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
--- Comment #5 from davidxl ---
(In reply to wmi from comment #4)
> Can we move the pure/const resetting loop to an earlier place: inside
> branch_prob , after instrument_edges and before gsi_commit_edge_inserts
> (where stmt_ends_bb_p is checke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61571
--- Comment #5 from davidxl ---
Thanks for the analysis. I agree it is invalid to use -fstrict-aliasing for
the code.
The implementation tries to save some space in __list_impl class by making the
sentinel marker __end_ to be just __list_node_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61571
davidxl changed:
What|Removed |Added
CC||richard.guenther at gmail dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61571
--- Comment #1 from davidxl ---
Created attachment 32979
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32979&action=edit
source file
end
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Compile the attached source with -m32 -std=c++11 -O2 on x86, the program will
crash. It runs fine with -m32 -std=c++11 -O2 -fno-tree-pre -fno-tree-fre.
(same failure is also observed on arm target).
The
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Build the following program with -fno-exceptions -O2, the program aborts at
runtime.
Adding -fno-tree-dominator-opts, the program runs fine.
To trigger the problem, the first iteration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #10 from davidxl ---
(In reply to Jeffrey A. Law from comment #9)
> Sorry, personal issue taking an enormous amount of my time right now. I
> have a fully tested patch and just need to twiddle the attached test into an
> executable te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
--- Comment #7 from davidxl ---
(In reply to Paul Pluzhnikov from comment #6)
> Google ref: b/13453242
Verified that the proposed patch fixed the problem in b/1345242.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
--- Comment #4 from davidxl ---
(In reply to davidxl from comment #3)
> (In reply to Jan Hubicka from comment #2)
> > David,
> > it seems a_m.C should be different form a.C. From chain of events you
> > describe I think
> > we need to figure out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
--- Comment #3 from davidxl ---
(In reply to Jan Hubicka from comment #2)
> David,
> it seems a_m.C should be different form a.C. From chain of events you
> describe I think
> we need to figure out why the last folding happens. Does the function
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Build the following code with the following command line:
g++ -O2 -fdisable-tree-einline a.cc a_m.cc
results in:
/tmp/cci31j3N.o: In function `D
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #6 from davidxl ---
I am working on a solution (and some cleanups).
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #5 from davidxl ---
Fixing this requires more powerful predicate analysis with the help of value
equivalent classes.
>From the dump:
"Use in stmt blah (v_1);
is guarded by :
if (_23 != 0)"
_23 = pephitmp_22 | _8,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59376
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
--- Comment #5 from davidxl ---
Alternative approach -- introduce a special forward propagation before or after
the ivopt to get rid of the redundant iv. This propagation needs to propagate
through header phi.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
--- Comment #16 from davidxl ---
(In reply to Richard Biener from comment #15)
> Confirmed. David, can you have a look here? I had a hard time following
> what
> exactly to do with the dataflow in the uninit pass for abnormal control flow
> (abn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490
--- Comment #5 from davidxl 2013-03-08 16:21:13
UTC ---
(In reply to comment #4)
> Clearly the limiting is bougs ... the issue is with large fanout BBs
> we recurse in compute_control_dep_chain which leads to exponential
> complexity. Li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #34 from davidxl 2013-01-18 17:27:43
UTC ---
The patch is missing changes in documentation on the new attribute.
David
(In reply to comment #32)
> Created attachment 29207 [details]
> gcc48-pr55742.patch
>
> This b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #30 from davidxl 2013-01-17 22:45:22
UTC ---
(In reply to comment #26)
> On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org
> wrote:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
> >
> > --- Comment #25
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #22 from davidxl 2013-01-15 19:03:03
UTC ---
(In reply to comment #21)
> What does it mean to merge two declarations with different target attributes?
> Are the strings just combined?
This is a good question. 'merge' needs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #20 from davidxl 2013-01-14 20:29:54
UTC ---
(In reply to comment #19)
> That wouldn't work, because you would then have the default (non-mv) version,
> possibly mv version with no target attribute, and then some other mv versi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #18 from davidxl 2013-01-14 20:17:45
UTC ---
All target attributes on decls not tagged with 'mv' attribute should be merged
into the default definition. Any decl tagged with 'mv' should be treated as a
new decl.
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #14 from davidxl 2013-01-14 17:49:59
UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > Either use a different name of the attribute (replace target with
> > > mv_target or
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #12 from davidxl 2013-01-14 17:20:56
UTC ---
(In reply to comment #10)
> Either use a different name of the attribute (replace target with mv_target or
> whatever), or require a new attribute (mv?) to be present for multi-versi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #11 from davidxl 2013-01-14 17:17:21
UTC ---
(In reply to comment #9)
> I'd say once a target attribute appears at a declaration (non-definition) MV
> needs to be disabled. Or, the declarations target attribute and those at
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
--- Comment #5 from davidxl 2012-11-21 16:17:27
UTC ---
Should the main variant types gets laid out in gimplify_type_sizes, when the
variant's type has size, but the main variant is incomplete?
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55376
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
--- Comment #2 from davidxl 2012-11-09 06:05:43
UTC ---
(In reply to comment #1)
> The problem actually exists in main line compiler too.
This is another test case.
Segfaults without option, but builds ok with -DOK.
The problem s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
davidxl changed:
What|Removed |Added
Version|4.7.3 |4.8.0
--- Comment #1 from davidxl 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
Bug #: 55245
Summary: Compiler segfault when compiling the small test case
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35310
--- Comment #2 from davidxl 2012-10-31 21:17:27
UTC ---
GCC is still not generating good code here, neither does ICC.
However LLVM does a good job here.
David
(In reply to comment #1)
> Confirmed. Looks like something for post
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35305
--- Comment #4 from davidxl 2012-10-30 18:57:18
UTC ---
The suggested transformation can be useful in some cases, but won't be general
enough. The listed example is an extreme case. For instance, the second a+b
instance does not have to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35357
--- Comment #2 from davidxl 2012-10-26 16:55:48
UTC ---
(In reply to comment #1)
> What is the expected optimization and what is its benefit?
Should be transformed into the following the simplified loop body.
void foo(int n)
{
i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605
--- Comment #7 from davidxl 2012-06-13 22:32:20
UTC ---
thanks for the fix. Is the fix going to be in gcc-4_7 branch?
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53605
Bug #: 53605
Summary: Compiler ICEs in size_binop_loc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #20 from davidxl 2012-05-10 20:45:58
UTC ---
Auto Cloning is an independent feature. What is requested here is an extension
of a previous auto clone patch by Sri (which is based on command line option
-mversion=...).
David
(In repl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
--- Comment #9 from davidxl 2012-05-08 00:16:30
UTC ---
c++11 defines the lifetime of a temporary -- does it match C or g++'s semantics
of compound literals or neither?
Note that without your change, the original program may also be subject to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
--- Comment #7 from davidxl 2012-05-07 17:03:51
UTC ---
Yes, the array case should be warned or disallowed if 1 is the way to go.
I won't call it a lousy choice -- the C++ semantics of the compound literals
allow more agressive optimization and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
--- Comment #5 from davidxl 2012-05-07 16:18:13
UTC ---
So it is possible either
1) to keep the current G++ semantics of compound literals, but change its
behavior due to the implementation change (with clobber marker);
or
2) to change hte G++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
--- Comment #1 from davidxl 2012-04-23 17:37:40
UTC ---
Created attachment 27223
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27223
benchmark source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090
Bug #: 53090
Summary: suboptimal ivopt
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53082
Bug #: 53082
Summary: local malloc/free optimization
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #4 from davidxl 2012-04-23 05:34:55
UTC ---
(In reply to comment #2)
> I should mention I made one patch before based on the vectorizer code which
> did
> detection of at least memset; it was while I was an intern at Apple. I posted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #3 from davidxl 2012-04-23 05:34:24
UTC ---
(In reply to comment #2)
> I should mention I made one patch before based on the vectorizer code which
> did
> detection of at least memset; it was while I was an intern at Apple. I posted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
Bug #: 53081
Summary: memcpy/memset loop recognition
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #11 from davidxl 2012-04-15 04:09:53
UTC ---
(In reply to comment #7)
> > > are against it). I don't think there is any GCC contributor that is paid
> > > to
> > > improve GCC's diagnostics (am I wrong?).
> >
> > Right, but partiall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #6 from davidxl 2012-04-13 05:01:56
UTC ---
I think you indirectly proved my point (see below) :)
(In reply to comment #5)
> Maintainers (those who decide) are too few and they either do not care or do
> not have time to fix these th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
--- Comment #4 from davidxl 2012-04-12 23:28:38
UTC ---
(In reply to comment #3)
> Yep, a dup.
>
> I am sorry David, but many of these deficiencies are well-known. What GCC
> sorely needs is people working on fixing them, and that is an issue th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52964
--- Comment #3 from davidxl 2012-04-12 23:19:33
UTC ---
(In reply to comment #2)
> And with trunk we print:
>
> pr52964.cc: In instantiation of ‘struct S1<4>’:
> pr52964.cc:2:49: required from ‘struct S2’
> pr52964.cc:3:45: required from ‘vo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52961
--- Comment #3 from davidxl 2012-04-12 23:11:10
UTC ---
(In reply to comment #2)
> Yes, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36478 .
thanks. I tried -Wempty-body, gcc gives warning as expected:
emptyif.cpp: In function 'int test(int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52964
Bug #: 52964
Summary: No warning on negative array size in template
instantatiation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52963
Bug #: 52963
Summary: Missing error on pack expansion
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52962
Bug #: 52962
Summary: Column number incorrect in error
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52961
Bug #: 52961
Summary: Missing warning on empty if
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960
Bug #: 52960
Summary: Missing warnings on ambiguous source : function decl
vs local var decl
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52959
Bug #: 52959
Summary: Missing typo suggestions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52958
Bug #: 52958
Summary: Missing warning on missed parehthesis
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957
Bug #: 52957
Summary: Missing suggestions on '=' and '==' confusion
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52956
Bug #: 52956
Summary: Missing overflow warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52955
Bug #: 52955
Summary: Missing warning on wrong sizeof usage
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52954
--- Comment #1 from davidxl 2012-04-12 21:56:07
UTC ---
Another example:
constexpr int arr_size = 42;
constexpr int N = 44;
void f(int);
int test() {
int arr[arr_size];
// ...
f(arr[N]);
// ...
if (N < arr_size) return arr[N];
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52954
Bug #: 52954
Summary: Missing bounds check warning
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #28 from davidxl 2012-01-11 17:26:46
UTC ---
See comment 24 for shorter test case.
Summary:
1) the regression reported by Oleg in gcc4_6 and earlier versions is due to FE
code generation difference which lead to the backend to gener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #22 from davidxl 2012-01-05 18:54:51
UTC ---
(In reply to comment #21)
> But can't a valid code also compare the result from realloc with the old
> pointer, and if they are equal, do something, otherwise do something else?
> I think i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #20 from davidxl 2012-01-05 18:11:18
UTC ---
(In reply to comment #19)
> On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> >
> > --- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #18 from davidxl 2012-01-04 17:11:26
UTC ---
(In reply to comment #17)
> On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> >
> > --- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from davidxl 2012-01-04 00:28:55
UTC ---
A related topic - aliasing property of realloc -- the malloc attribute is not
applied in the glibc header and the comment is like
/* __attribute_malloc__ is not used, because if realloc re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #25 from davidxl 2011-10-24 23:02:14
UTC ---
Created attachment 25600
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25600
test case for 47
Note that with gcc46, the result is even slower -- it has the RAT stall problem
which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #24 from davidxl 2011-10-24 23:00:22
UTC ---
(In reply to comment #23)
> Here is the source preprocessed for gcc47. The test exhibits the
> slowdown mentioned in comment 11.
The problem can be reproduced with a simplified test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #22 from davidxl 2011-10-24 19:58:23
UTC ---
(In reply to comment #21)
> OK, just in case, here is my current test.
Preprocessed test case? I saw the main assembly difference that can explain the
performance diff, but want to make su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #20 from davidxl 2011-10-24 19:33:18
UTC ---
The test.cpp attached seems to be the same as the old version.
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #15 from davidxl 2011-10-21 23:02:16
UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > David, it looks like we are seeing different things with v4.7... See my
> > comment 11 - I am still observing the slowdown. Do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #14 from davidxl 2011-09-15 17:28:10
UTC ---
(In reply to comment #13)
> David, it looks like we are seeing different things with v4.7... See my
> comment 11 - I am still observing the slowdown. Do you have access to
> v4.1 and v4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #8 from davidxl 2011-08-25 16:17:10
UTC ---
gcc46 and gcc47 difference can be reproduced using -O2 -m64.
David
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
--- Comment #3 from davidxl 2011-08-25 00:13:00
UTC ---
Caused by differences in FE generated code:
46:
D.6887 = (int) D.6886;
D.6888 = custom_constant_add::do_shift (D.6887);
D.6889 = (unsigned char) D.6888;
re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855
Summary: internal compiler error: in
fold_convert_const_int_from_real
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #6 from davidxl 2011-07-23 17:28:30
UTC ---
(In reply to comment #5)
> Any news on this item?
> Is this feature still foreseen for 4.7?
> A patch to test for instance.
Sri is working on this. He will post a formal specification of f
A. Law 2011-07-07
> 16:22:48 UTC ---
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/05/11 16:52, xinliangli at gmail dot com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
> >
> > --- Comment #7 from davidxl 2011-07-05
> 22:51:4
1 - 100 of 224 matches
Mail list logo
