[committed] Avoid -Wformat-security warning in libssp

2013-12-07 Thread Jakub Jelinek
Hi! libssp apparently doesn't build with -Werror=format-security which is planned to be default for Fedora. While this is a false positive, msg3 is always one of two string literals, I think it doesn't hurt to use %s there. Committed to trunk as obvious. --- libssp/ChangeLog(revision

Re: Cleanup Linux libc selection and Android support

2013-12-07 Thread Maxim Kuvyrkov
On 6/11/2013, at 1:44 pm, Maxim Kuvyrkov ma...@kugelworks.com wrote: On 19/09/2013, at 8:26 am, Maxim Kuvyrkov ma...@kugelworks.com wrote: Following recent breakage caused by adding nominal Android support to all *linux* targets [*] this patch series cleans up libc selection for Linux

Re: wide-int, rtl

2013-12-07 Thread Richard Sandiford
Kenneth Zadeck zad...@naturalbridge.com writes: +/* One could argue that GET_MODE_PRECISION (TYPE_MODE (type)) + should always be the same as TYPE_PRECISION (type). + However, it is not. Since we are converting from tree to + rtl, we have to expose this ugly truth here.

Re: [PATCH] Add -mtune=ia support

2013-12-07 Thread Gerald Pfeifer
On Fri, 6 Dec 2013, H.J. Lu wrote: http://en.wikipedia.org/wiki/IA IA-32, Intel Architecture, 32-bit IA-64, Intel Architecture, 64-bit And Intel 64 is an implementation of and extension to the 64-bit extension of IA-32 created by AMD, totally unrelated to IA-64. Marketing. :-) Gerald

Re: [REPOST] Invalid Code when reading from unaligned zero-sized array

2013-12-07 Thread Eric Botcazou
It's not fully fixing the issue as _all_ aggregates that may be accessed beyond their declarations size are broken. Sure, but we don't need to support such nonsense in the general case. And not every language allows it, for example in Ada you cannot do that of course. I'd say we should

Re: [wide-int] small cleanup in wide-int.*

2013-12-07 Thread Richard Sandiford
Kenneth Zadeck zad...@naturalbridge.com writes: #define WIDE_INT_MAX_ELTS \ - ((4 * MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ - / HOST_BITS_PER_WIDE_INT) + (((MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT - 1) \ +/ HOST_BITS_PER_WIDE_INT) + 1) I think this

Re: [REPOST] Invalid Code when reading from unaligned zero-sized array

2013-12-07 Thread Eric Botcazou
I'd certainly be concerned. Ports have (for better or worse) keyed on BLKmode rather than looking at the underlying types. So if something which was previously SImode or DImode is now BLKmode, there's a nonzero chance we're going to change how it gets passed. Well, we have been saying that

Re: [REPOST] Invalid Code when reading from unaligned zero-sized array

2013-12-07 Thread Eric Botcazou
That being said, the concern is certainly valid so we may want to go for a kludge instead of the fix. The point is that the kludge should do exactly what the fix would have done in the RTL expander and nothing more; it's out of question to pessimize all the other languages and all the other

Re: [patch] microblaze-rtems Add TARGET_BIG_ENDIAN_DEFAULT

2013-12-07 Thread Michael Eager
On 12/06/13 19:13, Ralf Corsepius wrote: Hi, I intend to the patch below to gcc-trunk and 4.8-branch: It's a partial sync of the microblaze-rtems* section in gcc/config.gcc with microblaze*-*-elf's: Add TARGET_BIG_ENDIAN_DEFAULT-switch for microblaze*-*-rtems*. Ralf OK. -- Michael Eager

[PATCH] -fuse-caller-save - Implement TARGET_FN_OTHER_HARD_REG_USAGE hook for MIPS

2013-12-07 Thread Tom de Vries
Richard, This patch implements the target hook TARGET_FN_OTHER_HARD_REG_USAGE (posted here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01318.html) for MIPS, to address the issue that $6 is sometimes used in split calls. Build and reg-tested on MIPS. OK for stage1? Thanks, - Tom

[Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)

2013-12-07 Thread Janus Weil
Hi all, here is a small patch to fix a problem with class-array-valued functions, where the rank was not determined properly. Regtestes on x86_64-unknown-linux-gnu. Ok for trunk? [Note: This patch only fixes the rejects-valid problem of comment 0/1, but not the ICE of comment 2/3, which is a

Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)

2013-12-07 Thread Tobias Burnus
Janus Weil wrote: here is a small patch to fix a problem with class-array-valued functions, where the rank was not determined properly. Regtestes on x86_64-unknown-linux-gnu. Ok for trunk? [Note: This patch only fixes the rejects-valid problem of comment 0/1, but not the ICE of comment 2/3,

Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)

2013-12-07 Thread Janus Weil
2013/12/7 Tobias Burnus bur...@net-b.de: Janus Weil wrote: here is a small patch to fix a problem with class-array-valued functions, where the rank was not determined properly. Regtestes on x86_64-unknown-linux-gnu. Ok for trunk? [Note: This patch only fixes the rejects-valid problem of

[C++ Patch] Fix __is_base_of vs incomplete types

2013-12-07 Thread Paolo Carlini
Hi, noticed this while preparing some testcases for the library (but probably Daniel pointed it out together with related issues some time ago): if we don't handle separately identical types modulo cv-qualifiers, we incorrectly return false for incomplete types. Tested x86_64-linux.

fixinclude patch for fenv.h on Ubuntu

2013-12-07 Thread Bruce Korb
This patch fixes Ian's issue, and several similar patterns: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00681.html $ make check autogen -T ../.././fixincludes/check.tpl ../.././fixincludes/inclhack.def /bin/sh ./check.sh ../.././fixincludes/tests/base Fixed: testing.h [[...]] Fixed: unistd.h