[committed] Avoid -Wformat-security warning in libssp
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 205753) +++ libssp/ChangeLog(working copy) @@ -1,3 +1,7 @@ +2013-12-07 Jakub Jelinek + + * ssp.c (fail): Avoid -Wformat-security warning. + 2013-09-20 Alan Modra * configure: Regenerate. --- libssp/ssp.c(revision 205753) +++ libssp/ssp.c(working copy) @@ -1,5 +1,5 @@ /* Stack protector support. - Copyright (C) 2005, 2009 Free Software Foundation, Inc. + Copyright (C) 2005-2013 Free Software Foundation, Inc. This file is part of GCC. @@ -136,7 +136,7 @@ fail (const char *msg1, size_t msg1len, #ifdef HAVE_SYSLOG_H /* Only send the error to syslog if there was no tty available. */ else -syslog (LOG_CRIT, msg3); +syslog (LOG_CRIT, "%s", msg3); #endif /* HAVE_SYSLOG_H */ /* Try very hard to exit. Note that signals may be blocked preventing Jakub
Re: Cleanup Linux libc selection and Android support
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), splits libc selection logic from >> Android support, and removes Android handling from targets that don't >> support it. > > Ping. Anyone wants to review these cleanup patches to config.gcc, config/t-* > and config/*.h files, or should I just start committing them quietly :-P ? This patch series was approved by Jeff Law, and I've committed them after retesting on current mainline. Thank you, -- Maxim Kuvyrkov www.kugelworks.com
Re: wide-int, rtl
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 = immed_wide_int_const (wide_int::from >> + (exp, >> +GET_MODE_PRECISION (TYPE_MODE (type)), >> +TYPE_SIGN (type)), >> + TYPE_MODE (type)); >> +return temp; >> + } >> >> I don't really see how one could argue that, given that there are much fewer >> modes than possible type precisions, so please rewrite the comment, e.g.: >> >> "Given that TYPE_PRECISION (type) is not always equal to >> GET_MODE_PRECISION (TYPE_MODE (type)), we need to extend from the former >> to the latter according to the signedness of the type". >> >> What about a fast track where the precisions are indeed equal? >> > > There is not really a faster track here.you still are starting with > a tree and converting to an rtx. All that the default one would do > would be to access the types precision and sign and use that. FWIW it would be: temp = immed_wide_int_const (exp, TYPE_MODE (type)); But it's hard to tell whether it would buy much. It didn't show up as a hot spot when I was doing performance measurements before. >> --- a/gcc/machmode.def >> +++ b/gcc/machmode.def >> @@ -229,6 +229,9 @@ UACCUM_MODE (USA, 4, 16, 16); /* 16.16 */ >> UACCUM_MODE (UDA, 8, 32, 32); /* 32.32 */ >> UACCUM_MODE (UTA, 16, 64, 64); /* 64.64 */ >> >> +/* Should be overridden by EXTRA_MODES_FILE if wrong. */ >> +#define MAX_BITS_PER_UNIT 8 >> + >> >> What is it for? It's not documented at all. >> > This requires some discussion as to the direction we want to go. This is > put in so that in gen_modes we can compute MAX_BITSIZE_MODE_ANY_INT and > MAX_BITSIZE_MODE_ANY_MODE.The problem is that during genmodes we do > have access to BITS_PER_UNIT.These two computed symbols are then > used as compile time constants in other parts of the compiler to > allocate data structures that are guaranteed to be large enough. > > Richard Sandiford put this in so we would preserve the ability to build > a multi-targetted compiler where the targets had different values for > BITS_PER_UNIT. So one possibility is that we add some documentation to > this effect. Sorry, I forgot yesterday an important detail behind why this seemed like a good thing. I think there was a strong feeling (from me and others) that wide-int.h shouldn't depend on tm.h. If we make wide-int.h depend on tm.h then basically all the compiler does. So as it stands we can't use BITS_PER_UNIT directly. Having a MAX_BITS_PER_UNIT for "all compiled-in targets" (which obviously as things stand is exactly one) seemed like a reasonable abstraction. Alternatively we could say that BITS_PER_UNIT is really part of the definition of QImode and move it to the modes.def file. Thanks, Richard
Re: [PATCH] Add -mtune=ia support
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
> 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 simply stop giving aggregates a mode besides BLKmode.
> What can possibly break with that ...
Nothing, but this will unnecessarily pessimize well-behaved languages, e.g. in
Ada we overalign structures in some cases to give them integral modes.
> struct { char c[4]; }
>
> has SImode, we accept all trailing arrays as possibly extending beyond the
> struct declaration.
>
> Alternatively all structs with aggregate members should not have a
> mode != BLKmode.
This could work as well, although I'd restrict this to arrays, recursively.
--
Eric Botcazou
Re: [wide-int] small cleanup in wide-int.*
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 this should be: (MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT + 1) We only need an extra HWI if MAX_BITSIZE_MODE_ANY_INT is an exact multiple of HOST_BITS_PER_WIDE_INT. >>> we will do this later when some other issues that Eric B raised are settled. >> I think you're talking about defining MAX_BITSIZE_MODE_ANY_INT as >> MAX_SIZE_MODE_ANY_INT * BITS_PER_UNIT, but that's orthogonal to the >> change above. IMO it doesn't make sense to both round up the division >> and also add 1 to the result. So I think we should make this change >> regardless of whatever follows. >> >> Looks good to me otherwise, thanks. >> >> Richard >> > so this one works the way you want.While it is true the the problems > are disjoint, the solution will likely evolving change the same lines of > source in two different ways. Well, if we're changing the definition of WIDE_INT_MAX_ELTS now (and we are) I think we should change it to something that makes sense. All we want is 1 extra bit. We don't need to round up the size and then add a whole HWI on top. Doing that will potentially pessimise targets that don't need anything beyond SImode. It's not like I can approve the patch anyway though, so I'll leave it there. Thanks, Richard
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
> 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 calling conventions need to be keyed on types rather than modes for more than a decade... I recall auditing and fixing the SPARC back-end circa 2003, so how long are we going to use this argument? 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 cases in the C family of languages for highly artificial testcases using non-portable code. -- Eric Botcazou
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
> 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 cases in > the C family of languages for highly artificial testcases using > non-portable code. What about: 1. a new boolean language hook support_trailing_arrays, 2. a new flag on RECORD_OR_UNION_TYPE_P types, 3. modifying stor-layout.c so that it sets the new flag on the appropriate types when support_trailing_arrays is true, 4. modifying expr.c along the lines of Bernd's latest idea to avoid returning anything but a MEM for objects with a type on which the flag is set? -- Eric Botcazou
Re: [patch] microblaze-rtems Add TARGET_BIG_ENDIAN_DEFAULT
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 Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[PATCH] -fuse-caller-save - Implement TARGET_FN_OTHER_HARD_REG_USAGE hook for MIPS
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-12 Chung-Lin Tang
Tom de Vries
* config/mips/mips.c (POST_CALL_TMP_REG): Define.
(mips_split_call): Use POST_CALL_TMP_REG.
(mips_fn_other_hard_reg_usage): New function.
(TARGET_FN_OTHER_HARD_REG_USAGE): Define targhook using new function.
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 36ba6df..3f60f5b 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -175,6 +175,11 @@ along with GCC; see the file COPYING3. If not see
/* Return the usual opcode for a nop. */
#define MIPS_NOP 0
+/* Temporary register that is used after a call, and suitable for both
+ MIPS16 and non-MIPS16 code. $4 and $5 are used for returning complex double
+ values in soft-float code, so $6 is the first suitable candidate. */
+#define POST_CALL_TMP_REG (GP_ARG_FIRST + 2)
+
/* Classifies an address.
ADDRESS_REG
@@ -6990,10 +6995,8 @@ mips_split_call (rtx insn, rtx call_pattern)
{
emit_call_insn (call_pattern);
if (!find_reg_note (insn, REG_NORETURN, 0))
-/* Pick a temporary register that is suitable for both MIPS16 and
- non-MIPS16 code. $4 and $5 are used for returning complex double
- values in soft-float code, so $6 is the first suitable candidate. */
-mips_restore_gp_from_cprestore_slot (gen_rtx_REG (Pmode, GP_ARG_FIRST + 2));
+mips_restore_gp_from_cprestore_slot (gen_rtx_REG (Pmode,
+ POST_CALL_TMP_REG));
}
/* Return true if a call to DECL may need to use JALX. */
@@ -18699,6 +18702,32 @@ mips_case_values_threshold (void)
else
return default_case_values_threshold ();
}
+
+/* Implement TARGET_FN_OTHER_HARD_REG_USAGE. */
+
+static void
+mips_fn_other_hard_reg_usage (struct hard_reg_set_container *fn_used_regs)
+{
+ /* POST_CALL_TMP_REG is used in splitting calls after register allocation.
+ With -fno-use-caller-save, the register is available because register
+ allocation ensures that members of call_used_regs are not live across
+ calls.
+ With -fuse-caller-save that's not the case, so we're missing a clobber on
+ the unsplit call insn to tell register allocation that the register is used
+ by the split call insn(s) after register allocation (we don't need the
+ clobber for a non-returning call, but we don't expect there will be a
+ penalty if we add the clobber for both returning and non-returning calls).
+
+ For the sake of simplicity we don't add the individual clobbers, but we use
+ this hook to mark the reg as clobbered. This is a bit ugly, since this
+ hook is called during the final pass on a function, and we're expressing
+ here that the insn after a call to this function will clobber a register.
+
+ The condition is the pass-independent part of TARGET_SPLIT_CALLS. */
+ if (TARGET_EXPLICIT_RELOCS
+ && TARGET_CALL_CLOBBERED_GP)
+SET_HARD_REG_BIT (fn_used_regs->set, POST_CALL_TMP_REG);
+}
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
@@ -18933,6 +18962,9 @@ mips_case_values_threshold (void)
#undef TARGET_CASE_VALUES_THRESHOLD
#define TARGET_CASE_VALUES_THRESHOLD mips_case_values_threshold
+#undef TARGET_FN_OTHER_HARD_REG_USAGE
+#define TARGET_FN_OTHER_HARD_REG_USAGE mips_fn_other_hard_reg_usage
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-mips.h"
[Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
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 completely separate issue.]
Cheers,
Janus
2013-12-07 Janus Weil
PR fortran/59414
* resolve.c (resolve_specific_f0): Handle CLASS-valued functions.
2013-12-07 Janus Weil
PR fortran/59414
* gfortran.dg/class_result_2.f90: New.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 205782)
+++ gcc/fortran/resolve.c (working copy)
@@ -2616,7 +2616,9 @@ found:
expr->ts = sym->ts;
expr->value.function.name = sym->name;
expr->value.function.esym = sym;
- if (sym->as != NULL)
+ if (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->as)
+expr->rank = CLASS_DATA (sym)->as->rank;
+ else if (sym->as != NULL)
expr->rank = sym->as->rank;
return MATCH_YES;
! { dg-do compile }
!
! PR 59414: [OOP] Class array pointers: compile error on valid code (Different ranks in pointer assignment)
!
! Contributed by Antony Lewis
implicit none
Type TObjectList
end Type
Class(TObjectList), pointer :: Arr(:)
Arr => ArrayItem()
contains
function ArrayItem() result(P)
Class(TObjectList), pointer :: P(:)
end function
end
Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
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, which is a completely separate issue.] Looks good to me. Thanks for the patch! Tobias 2013-12-07 Janus Weil PR fortran/59414 * resolve.c (resolve_specific_f0): Handle CLASS-valued functions. 2013-12-07 Janus Weil PR fortran/59414 * gfortran.dg/class_result_2.f90: New.
Re: [Patch, Fortran, OOP] PR 59414: Class array pointers: compile error on valid code (Different ranks in pointer assignment)
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 comment 0/1, >> but not the ICE of comment 2/3, which is a completely separate issue.] > > > Looks good to me. Thanks for the patch! Thanks for the review. Committed as r205785. Cheers, Janus
[C++ Patch] Fix __is_base_of vs incomplete types
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, Paolo. /cp 2013-12-07 Paolo Carlini * semantics.c (trait_expr_value, [CPTK_IS_BASE_OF]): Implement the letter of 20.11.6 about Base and Derived naming the same class type modulo cv-qualifiers. /testsuite 2013-12-07 Paolo Carlini * g++.dg/ext/is_base_of_incomplete-2.C: New. Index: cp/semantics.c === --- cp/semantics.c (revision 205782) +++ cp/semantics.c (working copy) @@ -7108,7 +7108,8 @@ trait_expr_value (cp_trait_kind kind, tree type1, case CPTK_IS_BASE_OF: return (NON_UNION_CLASS_TYPE_P (type1) && NON_UNION_CLASS_TYPE_P (type2) - && DERIVED_FROM_P (type1, type2)); + && (same_type_ignoring_top_level_qualifiers_p (type1, type2) + || DERIVED_FROM_P (type1, type2))); case CPTK_IS_CLASS: return (NON_UNION_CLASS_TYPE_P (type1)); Index: testsuite/g++.dg/ext/is_base_of_incomplete-2.C === --- testsuite/g++.dg/ext/is_base_of_incomplete-2.C (revision 0) +++ testsuite/g++.dg/ext/is_base_of_incomplete-2.C (working copy) @@ -0,0 +1,5 @@ +struct T; + +int check1[__is_base_of(T, T) ? 1 : -1]; +int check2[__is_base_of(T, const T) ? 1 : -1]; +int check3[__is_base_of(volatile T, T) ? 1 : -1];
fixinclude patch for fenv.h on Ubuntu
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
All fixinclude tests pass
/u/gnu/proj/gcc-svn-bld/build-x86_64-unknown-linux-gnu/fixincludes
Full build for x86-64 in progress. Patch submission likely tomorrow.
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog (revision 204533)
+++ fixincludes/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-09-20 Bruce Korb
+
+ * inclhack.def: many of the headers found under "bits/" are
+ often stashed under architecture directories. Apply fixes
+ to those, too. Also, re-ordered a couple of misordered fixes.
+
2013-09-20 Alan Modra
* configure: Regenerate.
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 204533)
+++ fixincludes/fixincl.x (working copy)
[[generated]]
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def (revision 204533)
+++ fixincludes/inclhack.def (working copy)
@@ -1140,6 +1140,20 @@
};
/*
+ * Old Linux kernel's header breaks Traditional CPP
+ */
+fix = {
+hackname = complier_h_tradcpp;
+files = linux/compiler.h;
+
+select= "#define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\)";
+c_fix = format;
+c_fix_arg = "/* __builtin_warning(x, y...) is obsolete */";
+
+test_text = "#define __builtin_warning(x, y...) (1)";
+};
+
+/*
* Fix various macros used to define ioctl numbers.
* The traditional syntax was:
*
@@ -1509,6 +1523,60 @@
};
/*
+ * Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ * that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname = feraiseexcept_nosse_invalid;
+mach = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= "^([\t ]*)__asm__ __volatile__ \\(\"divss %0, %0 *\" : "
+ ": \"x\" \\(__f\\)\\);$";
+bypass= "\"fdiv .*; fwait\"";
+
+c_fix = format;
+c_fix_arg = <<- _EOText_
+ # ifdef __SSE_MATH__
+ %0
+ # else
+ %1__asm__ __volatile__ ("fdiv st, st(0); fwait"
+ %1 : "=t" (__f) : "0" (__f));
+ # endif
+ _EOText_;
+
+test_text = <<- _EOText_
+ __asm__ __volatile__ ("divss %0, %0" : : "x" (__f));
+ _EOText_;
+};
+
+/*
+ * Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ * that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname = feraiseexcept_nosse_divbyzero;
+mach = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= "^([\t ]*)__asm__ __volatile__ \\(\"divss %1, %0 *\" : "
+ ": \"x\" \\(__f\\), \"x\" \\(__g\\)\\);$";
+bypass= "\"fdivp .*; fwait\"";
+
+c_fix = format;
+c_fix_arg = <<- _EOText_
+ # ifdef __SSE_MATH__
+ %0
+ # else
+ %1__asm__ __volatile__ ("fdivp st, st(1); fwait"
+ %1 : "=t" (__f) : "0" (__f), "u" (__g) : "st(1)");
+ # endif
+ _EOText_;
+
+test_text = <<- _EOText_
+ __asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
+ _EOText_;
+};
+
+/*
* Between 8/24/1998 and 2/17/2001, FreeBSD system headers presume
* neither the existence of GCC 3 nor its exact feature set yet break
* (by design?) when __GNUC__ is set beyond 2.
@@ -1738,7 +1806,7 @@
versions. */
fix = {
hackname = glibc_strncpy;
-files = bits/string2.h;
+files = bits/string2.h, '*/bits/string2.h';
bypass= "__builtin_strncpy";
c_fix = format;
c_fix_arg = "# define strncpy(dest, src, n) __builtin_strncpy (dest, src, n)";
@@ -2411,7 +2479,7 @@
*/
fix = {
hackname = huge_val_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= "^#[ \t]*define[ \t]*HUGE_VAL[ \t].*0x1\\.0p.*";
bypass= "__builtin_huge_val";
@@ -2426,7 +2494,7 @@
*/
fix = {
hackname = huge_valf_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= "^#[ \t]*define[ \t]*HUGE_VALF[ \t].*0x1\\.0p.*";
bypass= "__builtin_huge_valf";
@@ -2441,7 +2509,7 @@
*/
fix = {
hackname = huge_vall_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
select= "^#[ \t]*define[ \t]*HUGE_VALL[ \t].*0x1\\.0p.*";
bypass= "__builtin_huge_vall";
@@ -4226,7 +4294,7 @@
fix = {
hackname = thread_keyword;
files = "pthread.h";
-files = "bits/sigthread.h";
+files = bits/sigthread.h, '*/bits/sigthread.h';
select= "([* ])__thread([,)])";
c_fix = format
