On 12/27/2014 08:03 PM, Jonathan Wakely wrote:
On 28 December 2014 at 00:08, Olaf van der Spek wrote:
On 26-12-2014 1:52, Jonathan Wakely wrote:
On 25 December 2014 at 16:28, Olaf van der Spek wrote:
Hi,
https://gcc.gnu.org/ links to https://gcc.gnu.org/gcc-5/ (GCC 5 C++14
language
On Dec 29, 2014, at 2:01 PM, paul_kon...@dell.com paul_kon...@dell.com
wrote:
I would bug this but bugz says to report things under “bootstrap” only if
they are long lived failures, and I don’t know if this is.
Just tried to build on my Mac OS 10.10 system, plain native build. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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:
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=219098root=gccview=rev
Log:
2014-12-29 Janus Weil ja...@gcc.gnu.org
PR fortran/60357
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 anlauf at gmx dot de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Harald Anlauf anlauf at gmx dot de changed:
What|Removed |Added
CC||fxcoudert at gcc dot
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
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
---
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 redi at gcc dot gnu.org ---
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
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
---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368
--- Comment #11 from Hans-Peter Nilsson hp at gcc dot gnu.org ---
Created attachment 34344
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34344action=edit
Call-trace for testsuite/22_locale/locale/cons/6.cc on cris-elf, a newlib
target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
Andre Vehreschild vehre at gmx dot de changed:
What|Removed |Added
CC||vehre at gmx dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #5 from Harald Anlauf anlauf at gmx dot de ---
(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
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 ysrumyan at gmail dot com ---
Created attachment 34345
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34345action=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 anlauf at gmx dot de ---
(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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com ---
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 ysrumyan at gmail dot com ---
Created attachment 34348
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34348action=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 ysrumyan at gmail dot com ---
Created attachment 34349
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34349action=edit
assembly file before r216728
Assembly file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #6 from Yuri Rumyantsev ysrumyan at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64436
thopre01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #8 from Yuri Rumyantsev ysrumyan at gmail dot com ---
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
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 Xeon Phi
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=34350action=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=34351action=edit
pr64412.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|[5 Regression] Performance |[5 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On December 29, 2014 5:56:25 PM CET, ysrumyan at gmail dot com
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
--- Comment #8 from Yuri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #11 from Andre Vehreschild vehre at gmx dot de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
--- Comment #12 from Andre Vehreschild vehre at gmx dot de ---
Created attachment 34353
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34353action=edit
test_pr60357.f08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
--- Comment #5 from Andre Vehreschild vehre at gmx dot de ---
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579
--- Comment #3 from Anatol anatol.pomozov at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #1 from fredm dark_footix at yahoo dot fr ---
Created attachment 34355
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34355action=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 pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #3 from fredm dark_footix at yahoo dot fr ---
configure:4058: checking whether the C compiler works
configure:4080: ccache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
--- Comment #4 from fredm dark_footix at yahoo dot fr ---
cat conftest.c
/* confdefs.h */
#define PACKAGE_NAME
#define PACKAGE_TARNAME
#define PACKAGE_VERSION
#define PACKAGE_STRING
#define PACKAGE_BUGREPORT
#define PACKAGE_URL
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #1 from David Abdurachmanov david.abdurachmanov at gmail dot com
---
Created attachment 34356
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34356action=edit
RFC patch (tested)
Bootstrapped on aarch64-linux-gnu machine with F19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435
--- Comment #2 from David Abdurachmanov david.abdurachmanov at gmail dot com
---
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 34357
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34357action=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #7 from Harald Anlauf anlauf at gmx dot de ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Attachment #34341|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #9 from Harald Anlauf anlauf at gmx dot de ---
(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
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=34359action=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=34360action=edit
pr64412_2.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57037
--- Comment #1 from Harald Anlauf anlauf at gmx dot de ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64423
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63681
--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64412
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #34357|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64439
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64437
fredm dark_footix at yahoo dot fr changed:
What|Removed |Added
Status|WAITING |RESOLVED
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 pinskia at gcc dot gnu.org ---
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 pault at gcc dot gnu.org changed:
What|Removed |Added
CC||damian at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139
--- Comment #3 from nightstrike nightstrike at gmail dot com ---
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/bugzilla/show_bug.cgi?id=64440
--- Comment #2 from Chengnian Sun chengniansun at gmail dot com ---
(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
2014-12-24 Steve Ellcey sell...@mips.com
* config/mips/t-mti-linux (MULTILIB_EXCEPTIONS): Add exceptions
for mips32[r1] and mips64[r1] with -mnan=2008.
This is OK, but I think it may be best to fix t-mti-elf at the same
time even though it is probably building but with
Hi all,
attached is the patch and changelog for fixing pr60255. All comments I received
have been integrated into the current patch, therefore I submit this patch as
final and hope to see it in trunk soon.
The patch fixes the assignment of deferred length char arrays to unlimited
polymorphic
Hi Paul,
It looks good to me. I wonder if the testcase should not changed to { dg-do
run } and the allocatable component tested for not being allocated? You
might also consider adding an allocatable array component too
OK for trunk modulo considerations above
those are good points
Hi all,
here is a patch to improve diagnostics for dummy procedures. Regtested
on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2014-12-29 Janus Weil ja...@gcc.gnu.org
PR fortran/60507
* interface.c (is_procptr_result): New function to check if an
expression is a
Hi all,
this patches fixes PR60289 for allocating unlimited polymorphic entities
retyping them to a char array. The patch depends on my former patch for pr60255
at:
https://gcc.gnu.org/ml/fortran/2014-12/msg00130.html
because it needs the _len component introduced. I have extend Janus' patch
Hi All,
Here is a patch which fixed several performance degradation after
operand canonicalization (r216728). Very simple approach is used - if
operation is commutative and its second operand required more
operations (statements) for computation, swap operands.
Currently this is done under
On Mon, Dec 29, 2014 at 5:30 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi All,
Here is a patch which fixed several performance degradation after
operand canonicalization (r216728). Very simple approach is used - if
operation is commutative and its second operand required more
operations
Since 16bit byteswap can be done via an 8 bit rotation (and it is the canonical
form),
the check for an optab only serves to prevent the bswap optimization for
targets that don't have a 16bit byteswap (but do have a rotation instruction).
See
PR63259 (comments 6 and onwards) for more details.
Hi, all.
I would like to submit a patch for PR48956 mentioned in EasyHacks wiki
page. The patch includes several testcases. I bootstrapped the patched
source and tested it on x86_64-unknown-linux-gnu.
P.S. I'm completely new to GCC project, so I kindly ask someone to
review the patch and assist
Hi,
in this ICE on invalid, we crash during error recovery when
maybe_adjust_types_for_deduction gets an elt which has TREE_TYPE (elt)
== error_mark_node. I think we can simply check for that and return
unify_invalid. Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
Hi H.J.
Bug with reproducer was submitted:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
2014-12-29 16:53 GMT+03:00 H.J. Lu hjl.to...@gmail.com:
On Mon, Dec 29, 2014 at 5:30 AM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi All,
Here is a patch which fixed several performance
Missed path in ChangeLog:
2014-12-28 Evgeny Stupachenko evstu...@gmail.com
* config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Remove EBX register usage.
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Ditto.
On Sun, Dec 28, 2014 at 7:46 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
For the record, compiling the tests in pr61337 with the patch applied on top of
r219099 gives ICEs:
use array_list
1
internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
Since this replaces some wrong-code generation by some ICEs, I don’t think this
should delay the fix of
From: Matthew Fortune
2014-12-24 Steve Ellcey sell...@mips.com
* config/mips/t-mti-linux (MULTILIB_EXCEPTIONS): Add exceptions
for mips32[r1] and mips64[r1] with -mnan=2008.
This is OK, but I think it may be best to fix t-mti-elf at the same
time even though it is
On December 29, 2014 3:04:36 PM CET, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
Since 16bit byteswap can be done via an 8 bit rotation (and it is the
canonical form),
the check for an optab only serves to prevent the bswap optimization
for
targets that don't have a 16bit byteswap (but do
1 - 100 of 112 matches
Mail list logo
