, is happening.
More context is provided with -g than without, but I think this is
acceptable.
I bootstrapped and tested the attached patch on x86_64-redhat-linux-gnu,
with no new regressions.
--
Florian Weimer / Red Hat Product Security Team
gcc/
2014-05-13 Florian Weimer
* fold-const.c
On 02/03/2014 10:05 AM, Florian Weimer wrote:
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is
s:
<http://www.gnu.org/prep/standards/html_node/Formatting.html>
--
Florian Weimer / Red Hat Product Security Team
uot;. I don't think it's helpful.
In my opinion, it is better to make this message obsolete by introducing
the missing warning flags.
--
Florian Weimer / Red Hat Product Security Team
seems always
true, including the call in tre-vrp.c:infer_value_range, so there's a
minor cleanup opportunity.
Looking at infer_nonnull_range, there's an undocumented interaction with
-fdelete-null-pointer-checks.
--
Florian Weimer / Red Hat Product Security Team
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is ignored and this case needs instrumentation
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is ignored and this case needs instrumentation, as you
explained, so I use the function return
can just return the value of the condition, there's no need
for the if statement.
--
Florian Weimer / Red Hat Product Security Team
s have size 1 in C++, but structs with a zero-length array
have size 0, so the C++ compiler should be changed as well.
--
Florian Weimer / Red Hat Product Security Team
On 01/07/2014 02:37 PM, Jakub Jelinek wrote:
On Tue, Jan 07, 2014 at 02:27:04PM +0100, Florian Weimer wrote:
gimplify_modify_expr_rhs, in the CALL_EXPR case:
if (use_target)
{
CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1
On 01/07/2014 02:07 PM, Jakub Jelinek wrote:
On Tue, Jan 07, 2014 at 01:51:00PM +0100, Florian Weimer wrote:
+static bool
+stack_protect_return_slot_p ()
+{
+ basic_block bb;
+
+ FOR_ALL_BB_FN (bb, cfun)
+for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+!gsi_end_p (gsi
gcc.target/i386/pr59099.c fails on x86_64-redhat-linux-gnu with
--disable-multilib because linking -m32 code is not supported. The test
case passes in 64-bit mode as well. The other -m32 tests do not use
dg-do run, so they do not exhibit this problem.
Okay for trunk?
--
Florian Weimer
On 01/03/2014 10:43 PM, Florian Weimer wrote:
Lastly, I wonder if gimple_call_return_slot_opt_p is really what you are
after, why does NRV matter here?
The C code we generate does not construct the returned value in place
(presumably because the partial write would be visible with threads
BI thing, not really an optimization), but it's
closer to what I want.
--
Florian Weimer / Red Hat Product Security Team
++/Java enabled. Okay for trunk?
--
Florian Weimer / Red Hat Product Security Team
gcc/
2014-01-03 Florian Weimer
* cfgexpand.c (call_with_return_slot_opt_p): New function.
(expand_used_vars): Emit stack protector instrumentation in strong
mode if call_with_return_slot_opt_p.
gcc/testsuite
ly errors out on
class/struct mismatches (unless explicitly told to).
--
Florian Weimer / Red Hat Product Security Team
t think C provides a safe way to update interior pointers in
place, FWIW.)
--
Florian Weimer / Red Hat Product Security Team
that GCC cannot see across
translation units and spot crass declaration/definition mismatches.
--
Florian Weimer / Red Hat Product Security Team
you share the raw numbers? Are the differences statistically
significant?
--
Florian Weimer / Red Hat Product Security Team
I think. I can't parse the question at the end.
Sorry, no comments on the actual code changes. :-/
--
Florian Weimer / Red Hat Product Security Team
lictly prior to dereference? GCC would then warn if there is a path
on which the check is missing.
I don't have time at the moment to work on this, but it's on my
ever-growing TODO list. :)
--
Florian Weimer / Red Hat Product Security Team
As preapproved by Richard Biener. Bootstrapped on
x86_64-debian-linux-gnu.
2013-09-26 Florian Weimer
* tree-ssa.h (walk_use_def_chains_fn, walk_use_def_chains): Delete.
* tree-ssa.c (walk_use_def_chains_1, walk_use_def_chains): Delete.
* doc/tree-ssa.texi (Walking use
,
much like -fstack-protector.
I'm quite busy with other work at the moment, and a patch from me is
probably months away, though. :-(
--
Florian Weimer / Red Hat Product Security Team
On 08/25/2013 09:33 PM, Gerald Pfeifer wrote:
On Tue, 20 Aug 2013, Florian Weimer wrote:
As the libvtv reviewer, you don't need permission to commit your
changes. :-)
Actually, reviewers do need someone else's approval for their own
changes (unlike maintainers and of course not f
very tight in that an
int-cst or regular integers can be the operands of any wide-int
operation.
Are any of these conversions lossy? Maybe some of these constructors
should be made explicit?
--
Florian Weimer / Red Hat Product Security Team
ed patch?
--
Florian Weimer / Red Hat Product Security Team
Index: gcc/ipa.c
===
--- gcc/ipa.c (revision 201937)
+++ gcc/ipa.c (working copy)
@@ -1397,9 +1397,7 @@
static unsigned int
ipa_profile (void)
{
- struct cgraph_node
ision 201802)
+++ libvtv/vtv_utils.cc (working copy)
+ decriptor.
There's a stray space at the end of this line.
--
Florian Weimer / Red Hat Product Security Team
^
(The caret is at the wrong position, IMHO.)
But I suspect something went wrong with regenerating Makefile.in. Have
you got automake 1.11? Then you could make the change, regenerate
Makefile.in, and try again.
--
Florian Weimer / Red Hat Product Security Team
ep getenv".
It should print a line containing "secure_getenv" or "__secure_getenv",
but not plain "getenv".
--
Florian Weimer / Red Hat Product Security Team
up in
libvtv.so.
--
Florian Weimer / Red Hat Product Security Team
uot;_%d" should probably be dropped because the argument is not a
format string.
--
Florian Weimer / Red Hat Product Security Team
ave the intended security effect. I wonder if we can simply
label this functionality as unsafe for SUID/SGID programs, like we
(hopefully) do for profiling.
Also, logs_prefix should be declared const char *, then the cast can go
away (I hope).
--
Florian Weimer / Red Hat Product Security Team
behavior just be bugs? Depending on their error recovery
implementation, not flagging infinite recursion as a hard error in
SFINAE context could be an easy mistake to make.
--
Florian Weimer / Red Hat Product Security Team
g question, but hopefully we can make all errors due to
exceeded implementation limits hard errors, not subject to SFINAE.
--
Florian Weimer / Red Hat Product Security Team
levant autoconf checks are described here:
<http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv>
--
Florian Weimer / Red Hat Product Security Team
think it's useful to have parity
between the two front ends if possible.
I think the C++ ABI mandates that the implementation adds implicit locks
to enforce orderly initialization
Yes, that's how we implement it.
--
Florian Weimer / Red Hat Product Security Team
On 07/23/2013 09:51 PM, Andrew Pinski wrote:
On Tue, Jul 23, 2013 at 12:48 PM, Florian Weimer wrote:
We sometimes deal with code bases which use static local variables to cut
down frame size, for compatibility with legacy targets. Obviously, this is
bad for thread safety. This new warning
on x86_64-redhat-linux-gnu. Okay for
trunk?
--
Florian Weimer / Red Hat Product Security Team
gcc/ChangeLog:
2013-07-23 Florian Weimer
* doc/invoke.texi (Warning Options): Document -Wstatic-local.
c-family/ChangeLog:
2013-07-23 Florian Weimer
* c.opt (Wstatic-local): Add option
On 07/20/2013 02:09 AM, Andrew Pinski wrote:
gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}
I think this constructor should be marked "explicit".
--
Florian Weimer / Red Hat Product Security Team
*bytes.Buffer
The size of the public Decoder struct changes, and this size has been
compiled into client code.
--
Florian Weimer / Red Hat Product Security Team
On 07/05/2013 11:28 AM, Thomas Quinot wrote:
2013-07-06 Thomas Quinot
gcc/
* tree-complex.c: Fix minor typo in comment
OK to commit?
I think this falls under the "obvious" rule. (But your date in the
changelog is off.)
--
Florian Weimer / Red Hat Product Security Team
covers a tiny fraction of the problem. It's like bounds
checking for arrays which only fails if the index is at least twice as
large as the array length, IMHO.
--
Florian Weimer / Red Hat Product Security Team
verflow.
This whole feature seems rather poorly designed to me. The code size
increase due to official VLA support in C++11y might come a bit as a
surprise. But rereading N3639, there's no way around it, at least for
expressions of signed types.
--
Florian Weimer / Red Hat Product Security Team
On 05/06/2013 05:56 PM, Jason Merrill wrote:
On 05/06/2013 08:46 AM, Florian Weimer wrote:
On 05/06/2013 02:39 PM, Jason Merrill wrote:
On 05/06/2013 05:46 AM, Florian Weimer wrote:
Nice, this is simpler than expected. However, it makes the call sites
even more bloated.
Hmm, perhaps the
On 05/06/2013 02:39 PM, Jason Merrill wrote:
On 05/06/2013 05:46 AM, Florian Weimer wrote:
Nice, this is simpler than expected. However, it makes the call sites
even more bloated.
Hmm, perhaps the checking should be wrapped in an inline function, so
that the inliner can decide whether or not
nition,
which seems rather odd. I'm surprised that this even compiles.
--
Florian Weimer / Red Hat Product Security Team
logic handling '-fstack-protector-strong'.
* common.opt (fstack-protector-all): New option.
Should be "fstack-protector-strong".
--
Florian Weimer / Red Hat Product Security Team
- (E) the address from calling “alloca”
Function F is said to be vulnerable if its frame address is
exposed via (A) ~ (E).
What about struct-returning functions? Internally, an address is passed
to the called function. Would they trigger this? What about the this
pointer in C++ code?
--
Florian Weimer / Red Hat Product Security Team
On 04/09/2013 02:41 PM, Robert Dewar wrote:
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the
this a bit optimistic, considering that run-time overflow checking
currently does not use existing hardware support?
--
Florian Weimer / Red Hat Product Security Team
hecking code.)
Considering the range of different arithmetic operations we need to
support, I'm not convinced that the ring model is appropriate.
--
Florian Weimer / Red Hat Product Security Team
++ ABI, not the standard itself.
--
Florian Weimer / Red Hat Product Security Team
in()
{
return f() == 0;
}
--
Florian Weimer / Red Hat Product Security Team
ivial cost, it might make
sense to revamp C++ virtual method dispatch altogether, addressing both
security and modularity issues.
(Yes, I understand these two paragraphs go off in entirely different
directions. 8-)
--
Florian Weimer / Red Hat Product Security Team
library uses them internally? (That would be
quite a feat.)
--
Florian Weimer / Red Hat Product Security Team
* Uros Bizjak:
> +#elif defined(__x86_64__)
> +#define __cpuid(level, a, b, c, d) \
> + __asm__ ("xchg{q}\t{%%}rbx, %q1\n\t" \
> +"cpuid\n\t" \
> +"xchg{q}\t{%%}rbx, %q1\n\t" \
> +: "
t prints "application/xml" even for text
files. I fell into this trap as well, and have now filed a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=886005
--
Florian Weimer / Red Hat Product Security Team
On 11/23/2012 03:24 PM, Jason Merrill wrote:
On 11/23/2012 04:58 AM, Florian Weimer wrote:
Okay, this might work in the sense that it flags the relevant cases. I'm
still not convinced that this actually helps programmers that much
because it pretty much separates the two worlds. If this i
On 11/15/2012 02:51 AM, Jason Merrill wrote:
On 11/11/2012 11:58 PM, Jason Merrill wrote:
On 11/11/2012 08:01 AM, Florian Weimer wrote:
I'm not sure if this sufficiently far-reaching. It seems that this
doesn't allow me to implement a virtual function which takes a
std::string pa
on legacy headers, or some
form of automated cross-translation-unit feedback.
--
Florian Weimer / Red Hat Product Security Team
d-only, and
the elements might be ignored.)
--
Florian Weimer / Red Hat Product Security Team
On 11/06/2012 05:01 PM, Florian Weimer wrote:
On 11/06/2012 04:55 PM, Jason Merrill wrote:
On 11/05/2012 12:52 PM, Florian Weimer wrote:
+// Avoid use of none-overridable new/delete operators in shared
Typo: that should be "non-overridable"
Jason
Thanks, this patch fixes both
-free issues, heap spraying, or something else?
--
Florian Weimer / Red Hat Product Security Team
On 11/06/2012 04:55 PM, Jason Merrill wrote:
On 11/05/2012 12:52 PM, Florian Weimer wrote:
+// Avoid use of none-overridable new/delete operators in shared
Typo: that should be "non-overridable"
Jason
Thanks, this patch fixes both instances.
--
Florian Weimer / Red Hat Produc
On 11/02/2012 01:14 PM, Paolo Carlini wrote:
On 11/02/2012 01:09 PM, Florian Weimer wrote:
I looked at this again and made a new copy of the test case instead.
It has been successfully tested on x86_64-redhat-linux-gnu.
Is this okay for trunk?
Looks very nice to me, and after all the issue
On 10/30/2012 05:30 PM, Florian Weimer wrote:
On 10/30/2012 05:17 PM, Paolo Carlini wrote:
Sorry, I don't know the code well enough to review your patch, but
since I'm in CC, I still don't understand why, instead of adding a
full libstdc++ testcase you are extending a C++ testca
On 10/31/2012 06:13 PM, Florian Weimer wrote:
+ if (outer_nelts_check != NULL && inner_size.is_one())
Uhm, I will add the missing space before commit. Sorry.
--
Florian Weimer / Red Hat Product Security Team
son to chime in too.
Thanks, I'm attaching the updated patch.
Bootstrapped and tested on x86_64-redhat-linux-gnu, with no apparent
regressions.
--
Florian Weimer / Red Hat Product Security Team
gcc/:
2012-10-31 Florian Weimer
* init.c (build_new_1): Do not check for arithmetic over
addresses are passed to the tested functions). I really didn't want to
do that because there are some platform dependencies (the __ARM_EABI__
#ifdef).
Not sure if this makes sense, but those were my reasons.
--
Florian Weimer / Red Hat Product Security Team
On 09/17/2012 12:54 PM, Florian Weimer wrote:
On 09/17/2012 12:15 PM, Paolo Carlini wrote:
Hi,
On 09/17/2012 11:51 AM, Florian Weimer wrote:
On 08/21/2012 12:37 PM, Florian Weimer wrote:
I don't think there are any callers out there, but let's fix this for
completeness.
A compile
0) {
perror("close");
return 1;
}
int fd3 = dup(fd1);
if (fd3 < 0) {
perror("dup");
return 1;
}
return 0;
}
--
Florian Weimer / Red Hat Product Security Team
* Sam Varshavchik:
> Based on a casual browsing of clock_gettime(3), CLOCK_MONOTONIC_RAW
> seems to be a better fit for std::chrono::steady_clock's requirements
> as given in 20.11.7.2, with recent Linux kernels,
Are the Linux clock semantics documented somewhere in detail?
> +#ifdef CLOCK_MONO
93 TYPE_LANG_SPECIFIC (t)->u.c.vec_new_uses_cookie
5194 = type_requires_array_cookie (t);
I'm not sure if we've got proper test coverage for the concrete cookie
value, but the test case I've included implicitly check if there's a
cookie if there's a non-trivial destructor.
--
Florian Weimer / Red Hat Product Security Team
If the size of the inner array elements is 1 and we do not need a
cookie, we do not need to insert an overflow check. This applies to the
relatively frequent new char[n] case.
Built and regression-tested on x86_64-redhat-linux-gnu. Okay for trunk?
--
Florian Weimer / Red Hat Product
On 09/26/2012 10:19 PM, Tom Tromey wrote:
"Florian" == Florian Weimer writes:
Florian> This patch adds support for #pragma GCC warning and #pragma GCC
Florian> error. These pragmas can be used from preprocessor macros,
Florian> unlike the existing #warning and #error d
x86_64-redhat-linux-gnu, with no apparent
regressions. Okay for trunk?
--
Florian Weimer / Red Hat Product Security Team
gcc/ChangeLog:
2012-09-25 Florian Weimer
* doc/cpp.texi (Pragmas): Document #pragma GCC warning, #pragma
GCC error.
gcc/testsuite/ChangeLog:
2012-09-25 Florian Weimer
committed with these changes.
--
Florian Weimer / Red Hat Product Security Team
The attached patch is required so that plug-ins can include gimple.h. I
tested that cfg-flags.def is actually installed after this change.
Okay for trunk?
--
Florian Weimer / Red Hat Product Security Team
2012-09-17 Florian Weimer
* Makefile.in (BASIC_BLOCK_H): Add cfg-flags.def.
Index
On 09/17/2012 12:15 PM, Paolo Carlini wrote:
Hi,
On 09/17/2012 11:51 AM, Florian Weimer wrote:
On 08/21/2012 12:37 PM, Florian Weimer wrote:
I don't think there are any callers out there, but let's fix this for
completeness.
A compiler emitting code to call this function would sti
On 08/21/2012 12:37 PM, Florian Weimer wrote:
I don't think there are any callers out there, but let's fix this for
completeness.
A compiler emitting code to call this function would still have to
perform overflow checks for the new T[n][m] case, so this interface is
not as helpful a
On 09/05/2012 07:31 AM, Ian Lance Taylor wrote:
On Wed, Aug 29, 2012 at 10:32 AM, Florian Weimer wrote:
This patches fixes an integer overflow in libiberty, which leads to
crashes in binutils. The long version of the objalloc_alloc macro
would have needed another conditional, so I removed
equired path transformations (which are somewhat
system-specific).
--
Florian Weimer / Red Hat Product Security Team
not suffer from this problem:
<http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01986.html>
--
Florian Weimer / Red Hat Product Security Team
use this function in
GCC, therefore I want to commit this just to the trunk.
2012-08-29 Florian Weimer
PR other/54411
* objalloc.h (objalloc_alloc): Always use the simple definition of
the macro.
2012-08-29 Florian Weimer
PR other/54411
* objalloc.c
_64-redhat-linux-gnu.
--
Florian Weimer / Red Hat Product Security Team
2012-08-21 Florian Weimer
* libsupc++/vec.cc (compute_size): New function.
(__cxa_vec_new2, __cxa_vec_new3): Use it.
2012-08-21 Florian Weimer
* g++.old-deja/g++.abi/cxa_vec.C (test5, test6): New.
diff --git a/gcc/t
PATH_MAX), but these have not fared well can
turn out very difficult to use correctly over time (readdir_r being an
example).
--
Florian Weimer / Red Hat Product Security Team
to require optimization, alas).
--
Florian Weimer / Red Hat Product Security Team
commit 324c7189c9cf871584da988f12d1a686df0d6e0c
Author: Florian Weimer
Date: Fri Aug 17 18:19:13 2012 +0200
Implement -Wunbound-parameter-write (proof of concept)
diff --git a/gcc/builtins.c b/gcc/builtins.c
ind
e function, and the FEs
only provide the last one right now.
Could you pick the second argument for varargs functions? Incredibly
hacky, but would do the trick for those two. Or does the FE not know at
this point it is processing a varargs function?
--
Florian Weimer / Red Hat Product Security Team
f them already lowered at this
point?
--
Florian Weimer / Red Hat Product Security Team
On 07/18/2012 04:31 PM, Florian Weimer wrote:
On 07/18/2012 03:55 PM, Jason Merrill wrote:
On 06/26/2012 10:29 AM, Florian Weimer wrote:
+ /* Set to (size_t)-1 if the size check fails. */
+ if (size_check != NULL_TREE)
+*size = fold_build3 (COND_EXPR, sizetype, size_check
On 07/31/2012 11:58 AM, Florian Weimer wrote:
The attached patch adds a context parameter to
cxx_eval_constant_expression and its subprograms. This way, we do not
have to thread all context parameters manually. This will simplify the
introduction of additional location information, as
gcc-patches/2012-06/msg01596.html>.
Bootstrapped and tested on x86_64-redhat-linux-gnu.
--
Florian Weimer / Red Hat Product Security Team
2012-07-31 Florian Weimer
* semantics.c (cxx_eval_builtin_function_call): Introduce
const cxx_eval_constant_ctx * parameter.
(cxx_bind_parameters_i
On 07/18/2012 03:55 PM, Jason Merrill wrote:
On 06/26/2012 10:29 AM, Florian Weimer wrote:
+ /* Set to (size_t)-1 if the size check fails. */
+ if (size_check != NULL_TREE)
+*size = fold_build3 (COND_EXPR, sizetype, size_check,
+ original_size, TYPE_MAX_VALUE (sizetype
On 06/26/2012 04:29 PM, Florian Weimer wrote:
Bootstrapped and tested on x86_86-unknown-linux-gnu, with no new
regressions (this time including Java). Okay for trunk?
Ping?
--
Florian Weimer / Red Hat Product Security Team
On 06/14/2012 11:55 AM, Florian Weimer wrote:
This is another attempt at ensuring that operator new[] always returns a
block of sufficient size.
This is on top of my previous patch rejecting VLA allocations:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00616.html
I've committed the
On 06/25/2012 05:25 AM, Jason Merrill wrote:
On 06/11/2012 12:11 PM, Florian Weimer wrote:
+ tree inner_nelts_cst = maybe_constant_value (inner_nelts);
+ if (!TREE_CONSTANT (inner_nelts_cst))
+ {
+ if (complain & tf_error)
+ error_at (EXPR_LOC_OR_HERE (inner_nelts),
+ "array size in
This is another attempt at ensuring that operator new[] always returns a
block of sufficient size.
This is on top of my previous patch rejecting VLA allocations:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00616.html
Bootstrapped and tested on x86_64-linux-gnu.
--
Florian Weimer / Red Hat
On 06/01/2012 02:09 PM, Florian Weimer wrote:
On 06/01/2012 11:00 AM, Florian Weimer wrote:
I'll try to warn about this case and make the transformation to the
proper operator new[] call.
Here's the version. I've added a warning for the ill-formed code.
The only remaining
but
then we'd lose consistency.)
I'm going to look for tool support for locating such uses of operator[].
We might start recommending developers to switch to the at() member
functions in most code.
--
Florian Weimer / Red Hat Product Security Team
On 06/04/2012 10:46 PM, Jason Merrill wrote:
On 06/04/2012 04:12 PM, Florian Weimer wrote:
This doesn't make sense to me. parser->integral_constant_expression_p
should always be true at this point if you're moving the restore later
(which also seems unnecessary).
I
401 - 500 of 526 matches
Mail list logo
