' for z::aaa. With the patch the reference to
z::aaa is not folded, but its definition is not emitted either, so a undefined
reference error is produced at link time.
Technically, this is not a bug (for C++03 at least). But I do think
folding the constant is an important optimization.
--
Florian
On 11/13/2014 09:06 PM, mliska wrote:
+ Insert: O(2) amortized. O(1) actual.
This does not make much sense. Typo?
--
Florian Weimer / Red Hat Product Security
:
http://www.gnu.org/prep/standards/html_node/Formatting.html
--
Florian Weimer / Red Hat Product Security Team
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 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 fwei
On 05/14/2014 11:34 AM, Richard Biener wrote:
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer fwei...@redhat.com wrote:
Patterns that trigger the optimization and warning can form after inlining,
and it can be rather difficult to figure out what exactly is causing the
warning. The inlining
On 05/14/2014 11:56 AM, Jakub Jelinek wrote:
On Tue, May 13, 2014 at 09:27:08PM +0200, Florian Weimer wrote:
Patterns that trigger the optimization and warning can form after
inlining, and it can be rather difficult to figure out what exactly
is causing the warning. The inlining context
is
implemented, it interferes with unused-variable warnings. I just want
to archive it for posterity.
--
Florian Weimer / Red Hat Product Security Team
commit dbb1a7d8ee583466f00502848866fbfe5f5e2ca8
Author: Florian Weimer fwei...@redhat.com
Date: Thu Jun 5 10:16:34 2014 +0200
Add -finit
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
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
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
__builtin_cpuid builtin
and cleanup cpiud.h.
It also makes writing solid inline assembly which has to use %ebx for
some reason much easier. We just fixed a glibc bug related to that.
--
Florian Weimer / Red Hat Product Security
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
* 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 \
+: =a (a), =r
library uses them internally? (That would be
quite a feat.)
--
Florian Weimer / Red Hat Product Security Team
, 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
Would something like this be useful?
--- develop.html.~1.114.~ 2011-03-26 10:44:52.0 +0100
+++ develop.html2011-03-26 10:58:49.311173994 +0100
@@ -434,13 +434,13 @@
| GCC 4.5.1 release (2010-07-31)
GCC 4.6 Stage 3 (starts
* Richard Guenther:
The idea is to include the copy-source revision on the trunk or the
respective branch, so that you can use the timeline to check whether a
particular change came before or after a release. Of course, this is
just an approximation, but it think it might still be useful.
-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 fwei...@redhat.com
* semantics.c (cxx_eval_builtin_function_call): Introduce
const cxx_eval_constant_ctx * parameter
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
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
already lowered at this
point?
--
Florian Weimer / Red Hat Product Security Team
, 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
to require optimization, alas).
--
Florian Weimer / Red Hat Product Security Team
commit 324c7189c9cf871584da988f12d1a686df0d6e0c
Author: Florian Weimer fwei...@redhat.com
Date: Fri Aug 17 18:19:13 2012 +0200
Implement -Wunbound-parameter-write (proof of concept)
diff --git a/gcc/builtins.c b/gcc
well can
turn out very difficult to use correctly over time (readdir_r being an
example).
--
Florian Weimer / Red Hat Product Security Team
-linux-gnu.
--
Florian Weimer / Red Hat Product Security Team
2012-08-21 Florian Weimer fwei...@redhat.com
* libsupc++/vec.cc (compute_size): New function.
(__cxa_vec_new2, __cxa_vec_new3): Use it.
2012-08-21 Florian Weimer fwei...@redhat.com
* g++.old-deja/g++.abi/cxa_vec.C (test5, test6
not use this function in
GCC, therefore I want to commit this just to the trunk.
2012-08-29 Florian Weimer f...@deneb.enyo.de
PR other/54411
* objalloc.h (objalloc_alloc): Always use the simple definition of
the macro.
2012-08-29 Florian Weimer f...@deneb.enyo.de
://gcc.gnu.org/ml/gcc-patches/2012-08/msg01986.html
--
Florian Weimer / Red Hat Product Security Team
system-specific).
--
Florian Weimer / Red Hat Product Security Team
-05-29 Florian Weimer fwei...@redhat.com
* include/bits/stl_vector.h (vector::_M_fortify_range_check):
New.
* (vector::operator[]): Call it.
* testsuite/23_containers/vector/element_access/2.cc: New.
--
Florian Weimer / Red Hat Product Security Team
Index: libstdc
this with -fpermissive?
2012-05-29 Florian Weimer fwei...@redhat.com
* init.c (build_new): Reject variably modified types.
2012-05-29 Florian Weimer fwei...@redhat.com
* g++.dg/init/new33.C: New.
--
Florian Weimer / Red Hat Product Security Team
Index: gcc/cp/init.c
list. Will resubmit there.
--
Florian Weimer / Red Hat Product Security Team
, but no luck
there.
--
Florian Weimer / Red Hat Product Security Team
// Testcase for invocation of constructors/destructors in operator new[].
// { dg-do run }
#include stdlib.h
struct E {
virtual ~E() { }
};
struct S {
S();
~S();
};
static int count;
static int max;
static int throwAfter
On 05/29/2012 06:00 PM, Florian Weimer wrote:
This patch flags operator new on variably modified types as an error.
If this is acceptable, this will simplify the implementation of the
C++11 requirement to throw std::bad_array_new_length instead of
allocating a memory region which is too short
. _FORTIFY_SOURCE users expect some performance hit.
In contrast to debugging mode, this does not change ABI and is more
widely applicable.
Okay for trunk?
2012-05-29 Florian Weimer fwei...@redhat.com
* include/bits/stl_vector.h (vector::_M_fortify_range_check):
New.
* (vector
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 glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically
to.
--
Florian Weimer / Red Hat Product Security Team
checks are implemented
(reliance upon __builtin_object_size in particular), it will always be
magic you cannot rely on, which makes good documentation difficult. But
we should at least explain that! (Obviously, the std::vector check
doesn't share this problem.)
--
Florian Weimer / Red Hat
in glibc headers, so you want
probably in the checking method declare it in some __gnu* namespace
as extern C __chk_fail () __attribute__((unused));
and then use.
Good point, thanks. I'm asking the libc folks if we may use this symbol
from libstdc++, just to be on the safe side.
--
Florian Weimer
On 06/01/2012 05:37 PM, Jason Merrill wrote:
On 06/01/2012 08:09 AM, Florian Weimer wrote:
The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (b is not a constant):
int (*x)[b] = new int[a][b]; // { dg-error not usable }
The new warning I've added fires
This patch adds a cross-reference to GNU libc and _FORTIFY_SOURCE (which
needs to be documented there) and mentions the optimization level
requirements.
Okay for trunk?
2012-06-04 Florian Weimer fwei...@redhat.com
* doc/extend.texi (Object Size Checking): Mention
On 06/04/2012 10:23 AM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 10:15:35AM +0200, Florian Weimer wrote:
--- gcc/doc/extend.texi (revision 187951)
+++ gcc/doc/extend.texi (working copy)
@@ -7376,8 +7376,15 @@
@findex __builtin___vfprintf_chk
GCC implements a limited buffer overflow
On 06/04/2012 11:01 AM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 10:34:21AM +0200, Florian Weimer wrote:
+This protection mechanism is only a last resort. As a programmer, you
+must not rely on its presence, but use explicit buffer length checks
+to avoid buffer overflows. GCC may
.
--
Florian Weimer / Red Hat Product Security Team
On 06/04/2012 12:11 PM, Jakub Jelinek wrote:
On Mon, Jun 04, 2012 at 11:59:59AM +0200, Florian Weimer wrote:
What about this?
+This protection mechanism is only a last resort. As a programmer, you
+must not rely on its presence, but use explicit buffer length checks
+to avoid buffer overflows
and C++98 mode. This removes several
spurious errors, and the testsuite is adjusted accordingly.
Bootstrapped on x86_64-linux-gnu with C, C++, TLO enabled, make
check-c++ passes with no regressions.
(Sorry if Thunderbird has garbled the changelog entries.)
2012-06-04 Florian Weimer fwei
, it passed on first try, which would be unusual.)
--
Florian Weimer / Red Hat Product Security Team
Index: libstdc++-v3/include/bits/c++config
===
--- libstdc++-v3/include/bits/c++config (revision 187951)
+++ libstdc++-v3/include/bits/c
On 06/04/2012 09:07 PM, Marc Glisse wrote:
On Mon, 4 Jun 2012, Florian Weimer wrote:
void
write(std::vectorfloat blob, unsigned n, float v1, float v2, float
v3, float v4)
{
blob[n] = v1;
blob[n + 1] = v2;
blob[n + 2] = v3;
blob[n + 3] = v4;
}
Would be great if it ended up testing only n and n
On 06/04/2012 08:40 PM, Jason Merrill wrote:
On 06/04/2012 06:36 AM, Florian Weimer wrote:
(Sorry if Thunderbird has garbled the changelog entries.)
I add the ChangeLog to the top of the patch to avoid this. :)
Good idea.
- if (TREE_CODE (w) != INTEGER_CST)
+ if (w == error_mark_node
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 think parser
, 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/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 glitch is in g
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/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 operator new
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 patch
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 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 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 for trivial
-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
As preapproved by Richard Biener. Bootstrapped on
x86_64-debian-linux-gnu.
2013-09-26 Florian Weimer f...@deneb.enyo.de
* 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
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
on the actual code changes. :-/
--
Florian Weimer / Red Hat Product Security Team
you share the raw numbers? Are the differences statistically
significant?
--
Florian Weimer / Red Hat Product Security Team
* Jason Merrill:
Sorry it's taken so long to review this.
Same here. *sigh* Thanks for your comments.
On 02/21/2011 04:05 PM, Florian Weimer wrote:
build_operator_new_call (tree fnname, VEC(tree,gc) **args,
-tree *size, tree *cookie_size
* Richard Guenther:
+ if (!flag_new_overflow_check)
+ return result;
Let's check for constant results here. If we have a TREE_CONSTANT
result that overflows, we can handle it even if we aren't emitting the
checks for non-constant values.
I assume I can report an error in this case?
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 compiler emitting
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
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 fwei...@redhat.com
* init.c (build_new_1): Do not check for arithmetic
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
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++ testcase, in old-deja
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 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 Product Security Team
issues, heap spraying, or something else?
--
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 instances.
I
might be ignored.)
--
Florian Weimer / Red Hat Product Security Team
headers, or some
form of automated cross-translation-unit feedback.
--
Florian Weimer / Red Hat Product Security Team
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 parameter
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
that GCC cannot see across
translation units and spot crass declaration/definition mismatches.
--
Florian Weimer / Red Hat Product Security Team
a safe way to update interior pointers in
place, FWIW.)
--
Florian Weimer / Red Hat Product Security Team
On 09/05/2012 07:31 AM, Ian Lance Taylor wrote:
On Wed, Aug 29, 2012 at 10:32 AM, Florian Weimer f...@deneb.enyo.de 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
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 as it looks
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 still have
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 fwei...@redhat.com
* Makefile.in (BASIC_BLOCK_H): Add cfg
after the variable declaration.
- (__len = __o-current_space\
+ (__len __len = __o-current_space \
Please write __len != 0 or len 0.
This is OK with those changes.
Thanks, committed with these changes.
--
Florian
on 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 fwei...@redhat.com
* doc/cpp.texi (Pragmas): Document #pragma GCC warning, #pragma
GCC error.
gcc/testsuite/ChangeLog:
2012-09
On 09/26/2012 10:19 PM, Tom Tromey wrote:
Florian == Florian Weimer fwei...@redhat.com 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 directives
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
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
* 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
fd3 = dup(fd1);
if (fd3 0) {
perror(dup);
return 1;
}
return 0;
}
--
Florian Weimer / Red Hat Product Security Team
rather odd. I'm surprised that this even compiles.
--
Florian Weimer / Red Hat Product Security Team
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
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
.
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
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
On 07/05/2013 11:28 AM, Thomas Quinot wrote:
2013-07-06 Thomas Quinot qui...@adacore.com
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
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
on x86_64-redhat-linux-gnu. Okay for
trunk?
--
Florian Weimer / Red Hat Product Security Team
gcc/ChangeLog:
2013-07-23 Florian Weimer fwei...@redhat.com
* doc/invoke.texi (Warning Options): Document -Wstatic-local.
c-family/ChangeLog:
2013-07-23 Florian Weimer fwei...@redhat.com
On 07/23/2013 09:51 PM, Andrew Pinski wrote:
On Tue, Jul 23, 2013 at 12:48 PM, Florian Weimer fwei...@redhat.com 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
1 - 100 of 520 matches
Mail list logo
