https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64076
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Bug ID: 64432
Summary: [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong
result for integer(4)::rate
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 29 10:45:21 2014
New Revision: 219098
URL: https://gcc.gnu.org/viewcvs?rev=219098&root=gcc&view=rev
Log:
2014-12-29 Janus Weil
PR fortran/60357
* array.c (ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #8 from janus at gcc dot gnu.org ---
The original problem in comment 0 is fixed with r219098. Thanks to Anthony for
reporting this!
TODO: The segfault reported by Dominique in comment 4 and 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #1 from Harald Anlauf ---
Modifying the test code as follows:
% cat gfcbug128b.f90
program gfcbug128b
integer(4) :: count_rate, count_max
call system_clock (count_rate=count_rate,count_max=count_max)
call system_clock (count_ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Harald Anlauf changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #0)
> I just discovered that the 20141227 snapshot breaks SYSTEM_CLOCK when
> the COUNT_RATE argument is a 32-bit integer:
Confirmed. Probably due to r211686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> What is the status of the patch in comment 4?
Alive 'n' kickin' ;)
Still applies (with a bit of fuzz) and regtests cleanly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #9 from Jonathan Wakely ---
Who is waving anything away? I've been fixing things for Darwin at all hours of
the day, while on vacation and while ill, so don't appreciate that comment.
I have run the years in valgrind and saw no probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Bug ID: 64433
Summary: Segmentation fault while compiling
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387
tocarip.intel at gmail dot com changed:
What|Removed |Added
CC||tocarip.intel at gmail do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387
--- Comment #2 from tocarip.intel at gmail dot com ---
Can also be reproduced with -mavx2 instead of -mavx512er.
Proposed patch fixes both cases.
Testing in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552
--- Comment #3 from janus at gcc dot gnu.org ---
This draft patch gets rid of the error and regtests cleanly:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(Revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Francois-Xavier Coudert changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot
gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #10 from Hans-Peter Nilsson ---
(In reply to Jonathan Wakely from comment #9)
> Who is waving anything away?
I wasn't referring to you. Apparently I was referring to a comment that was
supposed to be ignored.
> I've been fixing thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #11 from Hans-Peter Nilsson ---
Created attachment 34344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34344&action=edit
Call-trace for testsuite/22_locale/locale/cons/6.cc on cris-elf, a "newlib
target"
Plain execution trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
Andre Vehreschild changed:
What|Removed |Added
CC||vehre at gmx dot de
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #5 from Harald Anlauf ---
(In reply to Francois-Xavier Coudert from comment #4)
> I'm not sure this is a bug, but this was definitely by design (as the
> comment indicates). I think this is allowed by the successive standards
> (which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
Bug ID: 64434
Summary: Performance regression after operand canonicalization
(r216728).
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 34345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34345&action=edit
simple reproducer
Need to compile with -m32 on x86 platform.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> Also, the presence of a second argument (see comment #1) should
> not change the behavior.
To make that explicit:
% cat gfcbug128c.f90
program gfcbug128c
inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64393
tocarip.intel at gmail dot com changed:
What|Removed |Added
CC||tocarip.intel at gmail do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
Bug ID: 64435
Summary: [5.0.0 Regression] Bootstrap failure in libsanitizer
on AArch64 with Linux kernel <= 3.15
Product: gcc
Version: 5.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from H.J. Lu ---
Pleas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386
tocarip.intel at gmail dot com changed:
What|Removed |Added
CC||tocarip.intel at gmail do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #3 from Yuri Rumyantsev ---
I put into attachment two assembly files for test-case compiled with
"-O2 -m32 -S" options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #4 from Yuri Rumyantsev ---
Created attachment 34348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34348&action=edit
assembly files for test.c
Assembly file fro test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #5 from Yuri Rumyantsev ---
Created attachment 34349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34349&action=edit
assembly file before r216728
Assembly file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #6 from Yuri Rumyantsev ---
H.J.
I put before/after assembly files into bug attachment. We saw slowdown
on SLM and HSW for 32-bit on eembc2.0, e.g. des degradated on 36%
(SLM) and 7%(HSW). But we did not see slowdown on any 64-bit x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #7 from H.J. Lu ---
r216728 generates much longer code sequences. Where does it come from?
Does -m64 also generate longer code sequences?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64436
Bug ID: 64436
Summary: optimize-bswapdi-3.c fails on aarch64_be-none-elf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64436
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Andre Vehreschild from comment #9)
> I just need to
> figure, if allocating the component explicitly is valid in Fortran.
For sure. I think both the examples in comment 4 and 5 are ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #8 from Yuri Rumyantsev ---
The issue is caused by operand canonicalization, i.e. there is special
operand odering for commutative operations to have the same
representation for a + b and b + a. If computation of second operand
requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #4 from iverbin at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #3)
> (In reply to iverbin from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > (In reply to iverbin from comment #0)
> > > > To reproduce using Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #5 from iverbin at gcc dot gnu.org ---
Created attachment 34350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34350&action=edit
Source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #6 from iverbin at gcc dot gnu.org ---
Created attachment 34351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34351&action=edit
pr64412.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu changed:
What|Removed |Added
Summary|[5 Regression] Performance |[5 Regression] Performance
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #10 from rguenther at suse dot de ---
On December 29, 2014 5:56:25 PM CET, ysrumyan at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
>
>--- Comment #8 from Yuri Rumyantsev ---
>The issue is caused by opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #11 from Andre Vehreschild ---
Hi Janus,
before you invest too much time into that: My current patch level produces
intermediate code as attached (for a slightly different program, also
attached).
I was solving the (re-)alloc on assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #12 from Andre Vehreschild ---
Created attachment 34353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34353&action=edit
test_pr60357.f08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
--- Comment #5 from Andre Vehreschild ---
Patch available in:
https://gcc.gnu.org/ml/fortran/2014-12/msg00133.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
Bug ID: 64437
Summary: hang with iconv on the configure : "checking whether
the C compiler works"
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579
--- Comment #3 from Anatol ---
I just hit this issue when tried to build cross-tools for arm64.
CFLAGS_FOR_TARGET works as expected and I was assuming that CXXFLAGS_FOR_TARGET
is used instead of CXXFLAGS.
If CXXFLAGS_FOR_TARGET is not honored no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #1 from fredm ---
Created attachment 34355
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34355&action=edit
configure file of iconv
"checking whether the C compiler works" appear line 4048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #3 from fredm ---
configure:4058: checking whether the C compiler works
configure:4080: ccache
/home/sah0027/worksets/5.2.11e38_7241/sources/hardco/toolchain/broadcom/PROJ/broadcom_4.9.2/MAIN/bin/mipsel-linux-gcc
-O2 -ggdb3 -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #4 from fredm ---
cat conftest.c
/* confdefs.h */
#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define PACKAGE "libicon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from H.J. Lu ---
Confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #1 from David Abdurachmanov
---
Created attachment 34356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34356&action=edit
RFC patch (tested)
Bootstrapped on aarch64-linux-gnu machine with F19 + 3.12 and on QEMU with F21
+ 3.17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #2 from David Abdurachmanov
---
linux/version.h does not bring any additional kernel headers, its fully
standalone and seems fine to include.
There might be a problem is someone builds a distribution with GCC 5 and kernel
<=3.15 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438
Bug ID: 64438
Summary: Removing string-conversion requirement causes
libstdc++-v3 fails on AArch64.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
Oleg Endo changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #8 from H.J. Lu ---
Created attachment 34357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34357&action=edit
A patch
Can you try this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64439
Bug ID: 64439
Summary: Incorrect location of -Wunused-value or false negative
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #7 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > If you have another idea, please post a list of what you think should happen
> > in all various cases (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
Bernd Edlinger changed:
What|Removed |Added
Attachment #34341|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #9 from Harald Anlauf ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Manuel López-Ibáñez from comment #7)
> > The ideal fix for this would adding a function like:
>
> I forgot about this bug and redid the above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #9 from iverbin at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #8)
> Created attachment 34357 [details]
> A patch
>
> Can you try this?
Thank you, e.53.5.c now passed.
However for-3.c and for-11.C still fails with another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #10 from iverbin at gcc dot gnu.org ---
Created attachment 34359
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34359&action=edit
pr64412_2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #11 from iverbin at gcc dot gnu.org ---
Created attachment 34360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34360&action=edit
pr64412_2.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57037
--- Comment #1 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #0)
> gfortran (using -Ofast -fprefetch-loop-arrays) exactly
> reproduces the performance of the Intel compiler without
> temporal stores. It appears that this is an i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #5 from Mikael Pettersson ---
The ICE on bfin-elf started for 4.9 with r204985, and stopped for 5.0 with
r210683. Backporting r210683 to current 4.9 branch is easy and fixes the ICE
there too. I haven't checked c6x.
See also:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Harald Anlauf from comment #9)
> (In reply to Manuel López-Ibáñez from comment #8)
> > (In reply to Manuel López-Ibáñez from comment #7)
> > > The ideal fix for this would adding a functio
Get MBA, E-MBA , MMS, DMS, PGDBM ,DBM etc done without disturbing your job...
Any Certificate NO Donation / Percentage Barrier
International Attestations by Ministry of External Affairs and Foreign Affairs
(Charges apply*)
GIVE US AN OPPORTUNITY TO MAKE YOUR CAREER:
Please reply to this mail p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu changed:
What|Removed |Added
Attachment #34357|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64439
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
fredm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
Bug ID: 64440
Summary: -Wdiv-by-zero false negative on const variables
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
--- Comment #1 from Andrew Pinski ---
In C, const int is not a constant expression and -Wdiv-by-zero only warns about
integer constant expressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52010
Paul Thomas changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139
--- Comment #3 from nightstrike ---
Both cloog and ppl have been removed from GCC in favor of just isl.
GCC 4.8 removes ppl in 2012:
https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01470.html
GCC 5.0 removes cloog:
https://gcc.gnu.org/ml/gcc-patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64440
--- Comment #2 from Chengnian Sun ---
(In reply to Andrew Pinski from comment #1)
> In C, const int is not a constant expression and -Wdiv-by-zero only warns
> about integer constant expressions.
Thanks for your reply. It seems GCC sometimes do
83 matches
Mail list logo
