http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #22 from Paulo J. Matos pa...@matos-sorge.com ---
After some thought, I am concluding this cannot actually be optimized and that
GCC 4.5.4 was better because it was taking advantage of an undefined behaviour
that doesn't exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #20 from Paulo J. Matos pa...@matos-sorge.com ---
OK, I was trying to make sense of all this and there are two things that stick
out.
One is when you say that due to C integer promotion rules make i =
(short)((int)i + 1). However GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #13 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #12)
Note that {1, +, 1}_1 is unsigned. The issue is that while i is short
i++ is really i = (short)((int) i + 1) and thus only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
Something like this which looks much simpler hits the same problem:
extern int arr[];
void
foo32 (int limit)
{
short i;
for (i = 0; (int)i limit; i++)
arr[i] += 1;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #16 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
Exactly the same problem. C integral type promotion rules make
that i = (short)((int)i + 1) again. Note that (int)i + 1
does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #15)
On Thu, 6 Feb 2014, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo
Assignee: unassigned at gcc dot gnu.org
Reporter: pa...@matos-sorge.com
Created attachment 32073
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32073action=edit
Testcase
This might be a dup of PR52372 or PR57933 but since I am not sure I am opening
a new bug.
When trying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #7 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #5)
Apart from expand there is the redundant-extension-elimination, ree.c.
In expand we get the following gimple for the loop:
;; basic block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #8 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #7)
(In reply to Richard Biener from comment #5)
Apart from expand there is the redundant-extension-elimination, ree.c.
In expand we get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #9 from Paulo J. Matos pa...@matos-sorge.com ---
Created attachment 32044
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32044action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop basic block is:
;; basic block 5, loop depth 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #11 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #10)
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #2 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #1)
I guess pure co-incidence
If I understand you correctly you think that the patch I mentioned is not the
culprit but simply triggered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Richard Biener from comment #3)
Yes, I think that the IV choice merely shows that we miss to optimize the
extension - which would be somewhere in the RTL opt pipeline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Paulo J. Matos pa...@matos-sorge.com ---
humm, ree is no good because by then we missed already the generation of zero
overhead loops. Do you think this is something that could be added to expand?
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pa...@matos-sorge.com
Following the discussion in the mailing list thread:
http://gcc.gnu.org/ml/gcc/2014-01/msg00319.html
I removed the undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55025
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
CC||pa...@matos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #51 from Paulo J. Matos pa...@matos-sorge.com ---
This was in a private VLIW SIMD port.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #48 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #47)
Would like to add that I backported the patch locally and all the testsuite
is passing until now. The ICE I initially got is not gone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #49 from Paulo J. Matos pa...@matos-sorge.com ---
I noticed that enabling misaligned moves have created a few test failures on my
port. Namely: execute.exp=20051113-1.c. It was generating one too many moves to
deference the structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #47 from Paulo J. Matos pa...@matos-sorge.com ---
Would like to add that I backported the patch locally and all the testsuite is
passing until now. The ICE I initially got is not gone as well. So I can
confirm that as far as I know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #45 from Paulo J. Matos pa...@matos-sorge.com ---
Can we backport Bernd's patch of the 20th of September to 4.8?
I just met this ICE in 4.8 and I guess we should still try to fix them in 4.8
since it's still maintained.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #20 from Paulo J. Matos pa...@matos-sorge.com ---
Thanks for fixing this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #14 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Uroš Bizjak from comment #13)
(In reply to Paulo J. Matos from comment #9)
Unfortunately running one of these takes a long time so it's a slow process
to check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #9 from Paulo J. Matos pa...@matos-sorge.com ---
I didn't manage to reproduce the bug yet. With the git sha before my commit
4bc0f16, I get the following on a profiledbootstrap on x64:
insn-opinit.c: In function 'void init_all_optabs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
CC||pa...@matos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: pa...@matos-sorge.com
Created attachment 30976
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30976action=edit
Profiling files and preprocessed file resulting in ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
CC||pa...@matos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
--- Comment #2 from Paulo J. Matos pa...@matos-sorge.com ---
Here's my reading of the problem:
core_bench_list calls core_list_mergesort which indirectly (through a function
pointer) calls cmp_idx. The global max_count variable is updated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
--- Comment #3 from Paulo J. Matos pa...@matos-sorge.com ---
I have now a fix for this. I will prepare a patch for gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #3 from Paulo J. Matos pa...@matos-sorge.com ---
Thanks Richard, will check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com ---
Backporting fixes the problem. Can we go ahead and backport to 4.8?
Can we add the testcase to the testsuite as well please?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #6 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to rguent...@suse.de from comment #5)
On Fri, 20 Sep 2013, pa...@matos-sorge.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #4 from Paulo J
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pa...@matos-sorge.com
Created attachment 30855
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30855action=edit
Code example to reproduce ICE
GCC tries to access varmap through get_varinfo in tree-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
CC||pa...@matos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #18 from Paulo J. Matos pa...@matos-sorge.com ---
I notice(In reply to Brooks Moses from comment #12)
Now, if this replacement still happens when you compile with -nostdlib, that
would be a bug since it becomes legal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #11 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Brooks Moses from comment #10)
Other than the documentation issues, this seems like a non-bug.
A non-bug? If you write a memcpy function by hand and call it memcpy, gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #11 from Paulo J. Matos pa...@matos-sorge.com ---
No worries Marc, that's fine. The most important thing is that's fixed. I did
post the patch to patches@ but haven't actually pinged. I tend to forget about
them myself.
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #12 from Paulo J. Matos pa...@matos-sorge.com ---
Also, I haven't touched tree-tailcall.c on my patches but I can't see why you
would need to do it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345
--- Comment #1 from Paulo J. Matos pa...@matos-sorge.com 2013-05-08 08:58:54
UTC ---
I am revisiting this bug and it seems that there's just an extra work, nothing
specially unexplained and the correct URL for the problem is:
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345
--- Comment #2 from Paulo J. Matos pa...@matos-sorge.com 2013-05-08 09:09:30
UTC ---
Created attachment 30050
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30050
Patch with typo fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com 2013-05-08 14:24:08
UTC ---
This issue persists in HEAD, the submitted patch seems to have been forgotten.
Ping, ping.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235
--- Comment #6 from Paulo J. Matos pa...@matos-sorge.com 2013-05-08 20:20:00
UTC ---
(In reply to comment #5)
(In reply to comment #4)
This issue persists in HEAD, the submitted patch seems to have been
forgotten.
Ping, ping.
Ping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
CC||pa...@matos
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@matos-sorge.com
vcondu pattern is undocumented at:
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gccint/Standard-Names.html
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@matos-sorge.com
While doing some tests I came across this ICE:
int __attribute__((__target__(xpto)))
foo(int x)
{
if (x == 1)
return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #6 from Paulo J. Matos pa...@matos-sorge.com 2013-01-22 15:30:48
UTC ---
I have some further patches that replace the previously posted ones that I will
upload soon. Should these also be sent to gcc-patches or it's unnecessary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
Attachment #29014|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos pa...@matos-sorge.com changed:
What|Removed |Added
Attachment #29251|0 |1
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@matos-sorge.com
Created attachment 29013
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29013
breaks GCC4.7.2 x86_64
Hello,
process_assignment in tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #1 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 15:53:48
UTC ---
This happens for the negate_expr case too in the same switch.
I have a patch to fix this that I will upload momentarily.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #3 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 16:01:23
UTC ---
Created attachment 29014
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29014
Use built_int_cst only for integral types, otherwise use fold_build1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #4 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 16:58:08
UTC ---
I created a new patch from your comment to gcc-patches:
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index 5b1fd2b..8c7d142 100644
--- a/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #5 from Paulo J. Matos pa...@matos-sorge.com 2012-12-20 17:06:04
UTC ---
As per previous comments, I looks at build_one_cst and implemented
build_minus_one_cst:
tree
build_minus_one_cst (tree type)
{
switch (TREE_CODE
57 matches
Mail list logo
