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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
Paulo J. Matos changed:
What|Removed |Added
CC||pa...@matos-sorge.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345
--- Comment #1 from Paulo J. Matos 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://gcc.gnu.org/onlinedocs/gccin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345
--- Comment #2 from Paulo J. Matos 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 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 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 it on gcc-patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #11 from Paulo J. Matos ---
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 for sorting it out.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #12 from Paulo J. Matos ---
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=56888
--- Comment #11 from Paulo J. Matos ---
(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
replaces the function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #18 from Paulo J. Matos ---
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 in that case. But that's
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
Paulo J. Matos changed:
What|Removed |Added
CC||pa...@matos-sorge.com
--- Comment #3
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=30855&action=edit
Code example to reproduce ICE
GCC tries to access varmap through get_varinfo in t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #3 from Paulo J. Matos ---
Thanks Richard, will check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
--- Comment #4 from Paulo J. Matos ---
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 ---
(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
> >
> > --- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463
Paulo J. Matos changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
ormal
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=30976&action=edit
Profiling files and preprocessed file resu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
Paulo J. Matos changed:
What|Removed |Added
CC||pa...@matos-sorge.com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
--- Comment #2 from Paulo J. Matos ---
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 in the
beginning of inline_sm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
--- Comment #3 from Paulo J. Matos ---
I have now a fix for this. I will prepare a patch for gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58682
Paulo J. Matos changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
Paulo J. Matos changed:
What|Removed |Added
CC||pa...@matos-sorge.com
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #9 from Paulo J. Matos ---
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(target_optabs*)':
insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #14 from Paulo J. Matos ---
(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 it out since as far
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #20 from Paulo J. Matos ---
Thanks for fixing this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #47 from Paulo J. Matos ---
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, the patch is indeed fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #45 from Paulo J. Matos ---
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=57748
--- Comment #48 from Paulo J. Matos ---
(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 as well. So I can
> con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #49 from Paulo J. Matos ---
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 in function Sum.
Apply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #51 from Paulo J. Matos ---
This was in a private VLIW SIMD port.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55025
Paulo J. Matos changed:
What|Removed |Added
CC||pa...@matos-sorge.com
--- Comment #2
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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #1 from Paulo J. Matos 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 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 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/tree-tailcall.c
+++ b/g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #5 from Paulo J. Matos 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 (type))
{
case I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
--- Comment #6 from Paulo J. Matos 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 since
they're being po
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos changed:
What|Removed |Added
Attachment #29014|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55761
Paulo J. Matos changed:
What|Removed |Added
Attachment #29251|0 |1
is obsolete|
: 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=5
--- Comment #2 from Paulo J. Matos ---
(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 this to happen. It might be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Paulo J. Matos ---
(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.
Makes sense. My first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Paulo J. Matos ---
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #7 from Paulo J. Matos ---
(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 4, loop depth 0
;;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #8 from Paulo J. Matos ---
(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 the following gimpl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #9 from Paulo J. Matos ---
Created attachment 32044
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32044&action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Paulo J. Matos ---
(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
> ;;pred:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #11 from Paulo J. Matos ---
(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 basic block is:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #13 from Paulo J. Matos ---
(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 the operation in
> type 'int'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #14 from Paulo J. Matos ---
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 ---
(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 not overflow, (short) ((i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #17 from Paulo J. Matos ---
(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
Assignee: unassigned at gcc dot gnu.org
Reporter: pa...@matos-sorge.com
Created attachment 32073
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32073&action=edit
Testcase
This might be a dup of PR52372 or PR57933 but since I am not sure I am opening
a new bug.
When tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #20 from Paulo J. Matos ---
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 is doing i = (short) (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #22 from Paulo J. Matos ---
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.
The thought process is as fo
57 matches
Mail list logo
