https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64917
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041
--- Comment #1 from Andrew Pinski ---
I think the setting of fd to -1 is removed which is why there is no warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54829
--- Comment #9 from Daniel Santos ---
I appologize for my late response.
(In reply to Richard Earnshaw from comment #8)
> Unfortunately, computers don't to infinite precision arithmetic by default.
> That would perform a different comparison in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992
--- Comment #3 from Ishiura Lab Compiler Team ---
Looking only from outside, the two programs are virtually equal, so we
just wondered what hinders the optimization on one of the programs.
The Optimization on "opt.c" seems very strong, so we th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #17 from Jerry DeLisle ---
Created attachment 34765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34765&action=edit
Handle KIND=1 and KIND=2
This updated patch gives a proposed way to handle KIND=1 and KIND=2. This is
done by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941
--- Comment #7 from H.J. Lu ---
GCC 4.9.3 20150215 is OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
--- Comment #3 from Kazumoto Kojima ---
Created attachment 34761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34761&action=edit
CSiBE result-runtime.csv revision 220636 + patch C#1 with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
--- Comment #2 from Kazumoto Kojima ---
Created attachment 34760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34760&action=edit
CSiBE result-runtime.csv revision 220636 with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
--- Comment #3 from H.J. Lu ---
Created attachment 34759
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34759&action=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
--- Comment #2 from H.J. Lu ---
Does -fno-common fix the problem? If it is the case, we need to
treat common symbol differently for ia64 since
.commonb#,8,4
.commona#,4,4
won't be placed in small data section reachable via GP r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65064
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64850
--- Comment #2 from Kazumoto Kojima ---
Author: kkojima
Date: Sat Feb 14 23:50:25 2015
New Revision: 220711
URL: https://gcc.gnu.org/viewcvs?rev=220711&root=gcc&view=rev
Log:
PR testsuite/64850
Tweak acc_on_device* tests.
Modified:
trunk/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65065
Bug ID: 65065
Summary: ICE with -O3 -floop-block on bootstrap
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #14 from Dominique d'Humieres ---
The reason why the changes for gcc/fortran/simplify.c on 4.9 have not been
applied to 4.8 is that these changes apply to procs introduced on 4.9 at
r197159, but not on 4.8. AFAICT these changes are ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #15 from Bernd Edlinger ---
Created attachment 34758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34758&action=edit
Updated patch that also fixes pr64230.f90
(In reply to Dominique d'Humieres from comment #12)
> With any of t
/torture/pr60115.c -O
/usr/ia64-suse-linux/bin/ld: a.out: __gp does not cover short data segment
collect2: error: ld returned 1 exit status
Broken by r220674.
--- gcc-20150213/Build/pr60115.s2015-02-14 21:36:37.0 +0100
+++ gcc-20150214/Build/pr60115.s2015-02-14 21:35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941
--- Comment #5 from Brian M ---
I can give someone a KDE desktop to the actual machine to reproduce the failure
if you like.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #13 from Dominique d'Humieres ---
Bisecting the range given in comment 4 shows that this PR is fixed by r198155
for 4.9. The fix was supposed to be back ported to 4.8 by r198345. However
comparing the logs shows no entry for gcc/fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
--- Comment #20 from Mikael Morin ---
(In reply to Dominique d'Humieres from comment #19)
> > patch fixing comment #7
>
> Confirmed, but it doesn't fix the test in comment 2 (with the addition in
> comment 10).
Confirmed; for some reason it wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64941
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #14 from Mikael Morin ---
Bernd, do you have a reliable way to test a patch, checking for aliasing
violations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #13 from Mikael Morin ---
Created attachment 34757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34757&action=edit
Yet another attempt using TYPE_CANONICAL
this tries to remove any use of VIEW_CONVERT_EXPR by setting (well, tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
--- Comment #19 from Dominique d'Humieres ---
> patch fixing comment #7
Confirmed, but it doesn't fix the test in comment 2 (with the addition in
comment 10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
--- Comment #18 from Mikael Morin ---
Created attachment 34756
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34756&action=edit
patch fixing comment #7
(In reply to Mikael Morin from comment #17)
> Using Tobias' analysis in comment #14, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #12 from Dominique d'Humieres ---
With any of the patches the first test for pr64230 fails at run time with
At line 35 of file pr64230.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 't'
but the test gfortran.dg/class_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #11 from Mikael Morin ---
Created attachment 34755
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34755&action=edit
Another proposed fix
(In reply to Bernd Edlinger from comment #10)
> Yes, but I have no idea how to know how t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #38 from Mikael Morin ---
(In reply to Dominique d'Humieres from comment #37)
> > >[...]
> > >if (D.3430.chars.data != 0B)
> > > {
> > >__builtin_free ((void *) D.3430.chars.data);
> > > }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64768
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64768
--- Comment #8 from Marek Polacek ---
Author: mpolacek
Date: Sat Feb 14 11:25:19 2015
New Revision: 220708
URL: https://gcc.gnu.org/viewcvs?rev=220708&root=gcc&view=rev
Log:
PR c/64768
* c-decl.c (grokdeclarator): Set the range of a flex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #12 from Jiri Slaby ---
(In reply to Marek Polacek from comment #10)
> That's because on your architecture char is signed by default. Try adding
> "unsigned" or using -funsigned-char and the warning should be gone.
Ok, I wanted to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #11 from Jakub Jelinek ---
-funsigned-char is an option that shouldn't be used without serious
consideration.
That said, I think in that case the warning is intentional, you are indeed
passing a signed value to unsigned format. If yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64927
--- Comment #12 from Dominique d'Humieres ---
> I pulled yesterday's 4.8 snapshot, bootstrapped it to verify that
> the problem still existed, and applied the 1-liner from r198000.
> It does not fix the issue.
Confirmed, for the record, testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #10 from Marek Polacek ---
That's because on your architecture char is signed by default. Try adding
"unsigned" or using -funsigned-char and the warning should be gone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765
--- Comment #18 from Dominique d'Humieres ---
I think this PR is now fixed by r220654 for trunk (5.0) and r220659 (4.9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #37 from Dominique d'Humieres ---
> >[...]
> >if (D.3430.chars.data != 0B)
> > {
> >__builtin_free ((void *) D.3430.chars.data);
> > }
> >D.3430.chars.data = 0B;
>
> D.3430.chars.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
--- Comment #9 from Jiri Slaby ---
What about this?
#include
void x(char *ch)
{
printf("%x\n", ch[10]);
}
It still produces the warning. (I cannot reopen as I am not a reporter.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64963
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65063
Bug ID: 65063
Summary: gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3
-fno-tree-loop-ivcanon -fno-tree-vectorize
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64976
--- Comment #2 from hete2 at gmx dot de ---
Thank you for this hint.
Using this configure option the boootstrapping works. Therefore this report can
be renamed to a false warning about -Werror=maybe-uninitialized (if this is
considered a Bug) or g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62209
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sat Feb 14 08:23:18 2015
New Revision: 220706
URL: https://gcc.gnu.org/viewcvs?rev=220706&root=gcc&view=rev
Log:
PR tree-optimization/62209
* tree-ssa-reassoc.c (update_range_test
44 matches
Mail list logo
