hat
> decision right away.
I think we should try with _FORTIFY_SOURCE first. The above case looks
rather artificial. If there is a visible performance impact, maybe we
can get the compiler to eliminate the vector bounds checks in many cases.
--
Florian Weimer / Red Hat Product Security
On 09/10/2015 06:30 PM, Martin Sebor wrote:
> On 09/09/2015 09:58 AM, Florian Weimer wrote:
>> On 09/08/2015 05:45 PM, Jonathan Wakely wrote:
>>
>>>> I doubt we can achieve the complexity goals in all cases. I expect
>>>> that
>>>>
>>
I
expect the libstdc++ changes to be similar.
Again, my main argument is that the main users of _FORTIFY_SOURCE are
distributions, and they would inject whatever preprocessor macro enables
the new libstdc++ checks anyway, so saving them that work would be
preferable IMHO.
--
Florian Weimer / Red Hat Product Security
tion unit because any definition in another translation unit
would be an ODR violation, so they can be put into the anonymous
namespace themselves.
--
Florian Weimer / Red Hat Product Security
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 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 Produc
-free 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
d-only, and
the elements might be ignored.)
--
Florian Weimer / Red Hat Product Security Team
on legacy 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 pa
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
nition,
which seems 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 or not
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
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
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
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
*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/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
* doc/invoke.texi (Warning Options): Document -Wstatic-local.
c-family/ChangeLog:
2013-07-23 Florian Weimer
* c.opt (Wstatic-local): Add option
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
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
levant autoconf checks are described here:
<http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv>
--
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
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
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
uot;_%d" should probably be dropped because the argument is not a
format string.
--
Florian Weimer / Red Hat Product Security Team
up in
libvtv.so.
--
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
in()
{
return f() == 0;
}
--
Florian Weimer / Red Hat Product Security Team
++ ABI, not the standard itself.
--
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
this a bit optimistic, considering that run-time overflow checking
currently does not use existing hardware support?
--
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
- (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
logic handling '-fstack-protector-strong'.
* common.opt (fstack-protector-all): New option.
Should be "fstack-protector-strong".
--
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
, 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 05/14/2014 11:34 AM, Richard Biener wrote:
On Tue, May 13, 2014 at 9:27 PM, 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 at least
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 at
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
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
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
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
p is 'true' 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 o
s:
<http://www.gnu.org/prep/standards/html_node/Formatting.html>
--
Florian Weimer / Red Hat Product Security Team
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
* 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" \
> +: "
library uses them internally? (That would be
quite a feat.)
--
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
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
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
f them already lowered at this
point?
--
Florian Weimer / Red Hat Product Security Team
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
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
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
_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
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
not suffer from this problem:
<http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01986.html>
--
Florian Weimer / Red Hat Product Security Team
equired path transformations (which are somewhat
system-specific).
--
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 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
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/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
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
committed with these changes.
--
Florian Weimer / Red Hat Product Security Team
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
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
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
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/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
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
-05-29 Florian Weimer
* 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++-v3/include/bits
-fpermissive?
2012-05-29 Florian Weimer
* init.c (build_new): Reject variably modified types.
2012-05-29 Florian Weimer
* g++.dg/init/new33.C: New.
--
Florian Weimer / Red Hat Product Security Team
Index: gcc/cp/init.c
ry mailing list. Will resubmit there.
--
Florian Weimer / Red Hat Product Security Team
On 05/29/2012 06:41 PM, Gabriel Dos Reis wrote:
On Tue, May 29, 2012 at 11:00 AM, 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
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
* include/bits/stl_vector.h (vector::_M_fortify_range_check):
New.
* (vector::operator[]): Call it
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
t copying literally what GNU libc is
doing. I can change it to the shorter version if you want me to.
--
Florian Weimer / Red Hat Product Security Team
st additional 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.)
--
Floria
totyped 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
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
On 06/01/2012 06:19 PM, Jason Merrill wrote:
On 06/01/2012 11:40 AM, Florian Weimer wrote:
I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.
I'd accept a patch to change that.
I don't really now what I'm doing here. B
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
* doc/extend.texi (Object Size Checking): Mention
_FORTIFY_SOURCE, add caveat
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 not be
he problem is unsolvable in
the general case.
--
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 Flor
;m not sure the test case
actually ran (if it did, 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++co
On 06/04/2012 09:07 PM, Marc Glisse wrote:
On Mon, 4 Jun 2012, Florian Weimer wrote:
void
write(std::vector& 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
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
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
* 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 *
301 - 400 of 560 matches
Mail list logo
