[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 2057

Re: Cleanup Linux libc selection and Android support

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

Re: wide-int, rtl

2013-12-07 Thread Richard Sandiford
Kenneth Zadeck 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. */ >> +temp

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 si

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

2013-12-07 Thread Richard Sandiford
Kenneth Zadeck 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 t

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 th

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 othe

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 2013-11

[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 comp

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, whic

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 : > 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 commen

[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. Thanks,

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