RE: [Patch, MIPS] Remove some multilibs from mips-mti-linux-gnu target

2014-12-29 Thread Matthew Fortune
> 2014-12-24 Steve Ellcey > > * 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 warnings. Thanks, Ma

[PATCH, fortran, final] PR fortran/60255 Deferred character length

2014-12-29 Thread Andre Vehreschild
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 ent

Re: [Patch, Fortran, F08] PR 60357: structure constructor with unspecified values for allocatable components

2014-12-29 Thread Janus Weil
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 y

[Patch, Fortran] PR 60507: Passing function call into procedure argument not caught

2014-12-29 Thread Janus Weil
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 PR fortran/60507 * interface.c (is_procptr_result): New function to check if an expression is a procedure-pointer result

[PATCH, Fortran] PR fortran/60289 Fixing character array allocation for class(*) type variable

2014-12-29 Thread Andre Vehreschild
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 giv

[x86, PATCH] operand reordering for commutative operations

2014-12-29 Thread Yuri Rumyantsev
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 special

Re: [x86, PATCH] operand reordering for commutative operations

2014-12-29 Thread H.J. Lu
On Mon, Dec 29, 2014 at 5:30 AM, Yuri Rumyantsev 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 (statements)

[PATCH] Don't check for optab for 16bit bswap

2014-12-29 Thread Thomas Preud'homme
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. Ch

[PATCH, c] PR c/48956: diagnostics for conversions involving complex types

2014-12-29 Thread Mikhail Maltsev
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 m

[C++ Patch] PR 58614

2014-12-29 Thread Paolo Carlini
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 2014-12

Re: [x86, PATCH] operand reordering for commutative operations

2014-12-29 Thread Yuri Rumyantsev
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 : > On Mon, Dec 29, 2014 at 5:30 AM, Yuri Rumyantsev wrote: >> Hi All, >> >> Here is a patch which fixed several performance degradation after >> operand canonicaliz

Re: [PATCH, i386] Remove EBX usage from asm code

2014-12-29 Thread Evgeny Stupachenko
Missed path in ChangeLog: 2014-12-28 Evgeny Stupachenko * 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 wrote: > Hi, > > The patch removes EBX usage

Re: [PATCH, fortran, final] PR fortran/60255 Deferred character length

2014-12-29 Thread Dominique d'Humières
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 p

RE: [Patch, MIPS] Remove some multilibs from mips-mti-linux-gnu target

2014-12-29 Thread Steve Ellcey
> From: Matthew Fortune > > 2014-12-24 Steve Ellcey > > > > * 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 bui

Re: [PATCH] Don't check for optab for 16bit bswap

2014-12-29 Thread Richard Biener
On December 29, 2014 3:04:36 PM CET, Thomas Preud'homme 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 have a rotation >ins

RE: [PATCH] Don't check for optab for 16bit bswap

2014-12-29 Thread Thomas Preud'homme
> From: Richard Biener [mailto:rguent...@suse.de] > Sent: Monday, December 29, 2014 5:09 PM > > OK, but what about targets without a rotation optab? Is the fallback > expansion reasonable in all cases? To be honest I haven't checked. I thought being a treecode means it can always be expanded, us

Re: libsanitizer merge from upstream r221802

2014-12-29 Thread David Abdurachmanov
Hi, I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15, 3.16 and above are fine. __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned short. <=3.15 kernel will trigger static asserts in libsanitizer while compiling GCC. I created PR: https://gcc.

Re: libsanitizer merge from upstream r221802

2014-12-29 Thread David Abdurachmanov
Hi, I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15, 3.16 and above are fine. __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned short. <=3.15 kernel will trigger static asserts in libsanitizer while compiling GCC. I created PR: https://gcc.

RE: [PATCH] Don't check for optab for 16bit bswap

2014-12-29 Thread Oleg Endo
On Mon, 2014-12-29 at 17:53 +, Thomas Preud'homme wrote: > > From: Richard Biener [mailto:rguent...@suse.de] > > Sent: Monday, December 29, 2014 5:09 PM > > > > OK, but what about targets without a rotation optab? Is the fallback > > expansion reasonable in all cases? > > To be honest I have

[PATCH][ARM] FreeBSD ARM support, EABI, v3

2014-12-29 Thread Andreas Tobler
All, here is the third attempt to support ARM with FreeBSD. In the meantime we found another issue in the unwinder where I had to adapt some stuff. The unwind_phase2_forced function in libgcc calls a stop_fn function. This stop_fn is in FreeBSD's libthr implementation and is called thread_u

Re: std::stoi and std::to_string on MinGW

2014-12-29 Thread Tejas Belagod
On 22/12/14 16:41, Jonathan Wakely wrote: On 22/12/14 16:02 +0100, Kai Tietz wrote: 2014-12-20 3:28 GMT+01:00 Jonathan Wakely : People keep hitting the problem that std::stoi and std::to_string are not defined when using MinGW, because of the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id

Re: libsanitizer merge from upstream r221802

2014-12-29 Thread Jakub Jelinek
On Mon, Dec 29, 2014 at 07:36:42PM +0100, David Abdurachmanov wrote: > I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15, > 3.16 and above are fine. > > __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned > short. <=3.15 kernel will trigger stati

[BUILDROBOT, PATCH] config-list.mk: Extract target name correctly

2014-12-29 Thread Jan-Benedict Glaw
Hi! With my last change, `sed' is used to cut out the target name from a listed target. Since there may be additional OPTions encoded in the "target", I tried to get only the first submatch before an `OPT'. However, `sed' uses longest match, so I'm re-writing this using awk. If anybody is like

[PATCH] Instrument bit field and unaligned accesses for TSAN

2014-12-29 Thread Bernd Edlinger
Hi, I noticed that currently the tsan pass does not instrument bit fileld accesses or unaligned data. Thus some race conditions are not found by the sanitizer. Furthermore the function __tsan_vptr_update is not called with the correct parameters. This patch uses two already existing interfaces

[PATCH] Fix loop optimization when ZOL is not available in xtensa configuration

2014-12-29 Thread Max Filippov
Currently building gcc for xtensa configuration with XCHAL_HAVE_LOOPS set to 0 fails with the following error: xtensa.c:3952: undefined reference to `reorg_loops(bool, hw_doloop_hooks*)' Only compile target-specific zero-overhead loop optimization code when TARGET_LOOPS allows it. 2014-12-30

[PATCH] MIPS16/GCC: Optimise `__call_stub_' call stubs

2014-12-29 Thread Maciej W. Rozycki
On Wed, 19 Nov 2014, Maciej W. Rozycki wrote: > I have a second optimisation to make here too, but that triggers a > surprising bug in GNU LD where BFD code meant to discard unused stubs > appears not to work at all. So that'll have to be fixed first and it > also means the other optimisation

[patch, fortran] Fix for PR 47676

2014-12-29 Thread Thomas Koenig
Hello world, this patch fixes the long-standing bug. A missing temporary causes an invalid read in realloc_on_assign_5.f03 which only becomes noticable when setting MALLOC_CHECK_ or when using valgrind. The bug has three duplicates in the data base, so people keep stumbling across this. I have