Jason Merrill ja...@redhat.com writes:
It seems like your new code is a generalization of the old code for
handling substitution of a pack for itself (arg_from_parm_pack and
such) and the code for handling other packs with a single pack
expansion argument, and should replace those rather than
Jakub Jelinek ja...@redhat.com writes:
Fixed thusly, ok for trunk?
2012-11-27 Jakub Jelinek ja...@redhat.com
* asan.c (instrument_assignment): Instrument lhs only
for gimple_store_p and rhs1 only for gimple_assign_load_p.
This is OK, thanks.
And sorry for the delay.
--
Ok for trunk?
2012-11-27 Jakub Jelinek ja...@redhat.com
* asan.c (instrument_mem_region_access): Don't instrument
if base doesn't have pointer type or len integral type.
Add cast if len doesn't have size_t compatible type.
(instrument_builtin_call): Don't
Gabriel Dos Reis g...@integrable-solutions.net a écrit:
On Fri, Nov 16, 2012 at 8:51 AM, Jason Merrill ja...@redhat.com wrote:
Would it work to just do a cp_parser_commit_to_tentative_parse after we see
the '='?
I guess you mean in cp_parser_alias_declaration like in the updated
patch below?
Jiri Palecek jpale...@web.de a écrit:
Ulf Magnusson wrote:
On Wed, Nov 14, 2012 at 6:10 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
The following snippet:
class A {};
class B : public A {
typedef A super;
public:
class X {};
};
class C : public B {
typedef B
David Miller da...@davemloft.net writes:
From: Dodji Seketeli do...@redhat.com
Date: Thu, 15 Nov 2012 11:56:40 +0100
David Miller da...@davemloft.net wrote
From: Dodji Seketeli do...@redhat.com
Date: Wed, 14 Nov 2012 14:26:40 +0100
I guess we could do that. That would build
Jack Howarth howa...@bromo.med.uc.edu writes:
The Google branch is missing the required
interception/mach_override/mach_override.h and
interception/mach_override/mach_override.c files from compiler-rt svn
for darwin. I have posted what I believe to be the final patch which
eanbles
Hello,
Consider this short example:
1 templatetypename T
2 using AddConst = T const;
3
4 enum FwdEnum : int;
5
6 int main() {
7AddConstFwdEnum *ptr = nullptr;
8 }
At line 7, when we build the type for AddConstFwdEnum in
lookup_template_class_1,
I am friendly pinging the patch below ...
Dodji Seketeli do...@redhat.com a écrit:
Hello,
Consider this example:
1templateclass...I struct List {};
2templateint T struct Z {static const int value = T;};
3templateint...T using LZ = ListZT...;
4
I am friendly pinging the patch below ...
Dodji Seketeli do...@redhat.com a écrit:
Hello,
Consider this invalid example given in the PR, where T is not defined:
1templatetypename
2struct X {
3using type = T;
4};
g++ yields
Jason Merrill ja...@redhat.com writes:
On 11/16/2012 07:43 AM, Dodji Seketeli wrote:
So I guess that condition should be changed to TREE_CODE
(template_type) == ENUMERAL_TYPE, to specifically detect the member
enum of a class template case.
Why does that help? What is template_type
Tom Tromey tro...@redhat.com a écrit:
My build of gcc today tried to run autoconf in libsanitizer.
However, I had the wrong version in my path, so the build died.
In gcc it is normal to use AM_MAINTAINER_MODE to avoid this problem.
I think this is missing from libsanitizer/configure.ac due
Maybe Konstantin could Help with the review, as this touches libsanitizer?
Cheers.
Mike Stump mikest...@comcast.net writes:
On Nov 14, 2012, at 6:43 AM, Jack Howarth howa...@bromo.med.uc.edu wrote:
The attached patch assumes that mach_override/mach_override.h
and
David Miller da...@davemloft.net wrote
From: Dodji Seketeli do...@redhat.com
Date: Wed, 14 Nov 2012 14:26:40 +0100
I guess we could do that. That would build libsanitizer, but asan will
still not be available on sparc if the asan_shadow_offset() target hook
is not provided. Is that OK
a/ChangeLog b/ChangeLog
index 8cd3b23..f035803 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2012-11-15 Dodji Seketeli do...@redhat.com
+
+ * MAINTAINERS: (asan.c, related): Add myself.
+
2012-11-14 Roland McGrath mcgra...@google.com
* configure.ac (ENABLE_GOLD
Jakub Jelinek ja...@redhat.com writes:
2012-11-12 Jakub Jelinek ja...@redhat.com
* asan.c (report_error_func): Set DECL_IGNORED_P, don't touch
DECL_ASSEMBLER_NAME.
(asan_init_func): Likewise.
(asan_finish_file): Use void * instead of __asan_global * as
type
Diego Novillo dnovi...@google.com writes:
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc
This should be fixed by Dodji's recent patch. ASAN is not
David Miller da...@davemloft.net writes:
From: Diego Novillo dnovi...@google.com
Date: Tue, 13 Nov 2012 11:21:59 -0500
On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:
This has broken the build on every Linux target that hasn't added
the necessary cpu specific code
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc (Jakub, Dodji, are they there?
I can't check ATM).
No there are not, for
Jakub Jelinek ja...@redhat.com writes:
On Tue, Nov 13, 2012 at 02:17:55PM +0100, Dodji Seketeli wrote:
What do the maintainers think?
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe
Hello,
This patch builds libsanitizer only on x86_64 and i?86 linux targets
for now. I guess The build can be enabled on other targets when they
are ready.
OK for trunk?
ChangeLog:
* configure.ac: Enable libsanitizer just on x86 linux for now.
* configure: Re-generate.
---
domi...@lps.ens.fr (Dominique Dhumieres) writes:
Yes. And it shouldn't be just based on target CPU, but also based
on target OS, I don't think libsanitizer supports anything but linux (glibc
+ maybe android) right now, with some smaller or bigger tweaks it could
support darwin (but see the
deletions(-)
diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan
index d13a584..0345ac7 100644
--- a/gcc/ChangeLog.asan
+++ b/gcc/ChangeLog.asan
@@ -1,4 +1,32 @@
2012-10-11 Jakub Jelinek ja...@redhat.com
+ Xinliang David Li davi...@google.com
+ Dodji Seketeli do...@redhat.com
On 2012-11-02 15:57 , Dodji Seketeli wrote:
/* AddressSanitizer, a fast memory error detector.
- Copyright (C) 2011 Free Software Foundation, Inc.
+ Copyright (C) 2011, 2012 Free Software Foundation, Inc.
I *think* we should only mention 2012, but I don't know if code
100644
index 000..704aa61
--- /dev/null
+++ b/gcc/ChangeLog.asan
@@ -0,0 +1,12 @@
+2012-10-10 Wei Mi w...@google.com
+ Diego Novillo dnovi...@google.com
+ Dodji Seketeli do...@redhat.com
+
+ * Makefile.in: Add asan.c and its dependencies.
+ * common.opt: Add
Diego Novillo dnovi...@google.com writes:
I believe they layout the stack from right to left (top is to the
right). Feels like reading a middle earth map. Kostya, is my
recollection correct?
Yes, Konstantin replied to this already but I forgot to update the
patch cover letter (that I keep
Diego Novillo dnovi...@google.com writes:
On 2012-11-02 16:01 , Dodji Seketeli wrote:
* varasm.c: Include asan.h.
(assemble_noswitch_variable): Grow size by asan_red_zone_size
if decl is asan protected.
(place_block_symbol): Likewise.
(assemble_variable): If decl
Diego Novillo dnovi...@google.com writes:
On 2012-11-02 16:05 , Dodji Seketeli wrote:
+static bool
+maybe_instrument_builtin_call (gimple_stmt_iterator *iter)
+{
+ gimple call = gsi_stmt (*iter);
+ location_t loc = gimple_location (call);
+
+ if (!is_gimple_call (call))
+return
Diego Novillo dnovi...@google.com writes:
On 2012-11-02 16:10 , Dodji Seketeli wrote:
* configure.ac: Add libsanitizer to target_libraries.
* Makefile.def: Ditto.
* configure: Regenerate.
* Makefile.in: Regenerate.
* libsanitizer: New directory for asan runtime
Tobias Burnus bur...@net-b.de writes:
The attached test case ICEs (segfault) both on the asan branch and on
the trunk with Dodji's patches:
Thank you for reporting this.
I believe the neqw series of patches I have juste posted address this
issue.
To ease the testing, you can check out an
Following a request from Jakub, and given the fact that the patch set
have been reviewed by Diego, I have committed the last set of patches I
have posted to trunk.
This will hopefully ease the polishing work that has started already.
I am of course watching for the fall-outs.
--
Jakub Jelinek ja...@redhat.com writes:
On Mon, Nov 12, 2012 at 12:30:37PM +0100, Dodji Seketeli wrote:
+ For this function, the stack protected by asan will be organized as
+ follows, from the top of the stack to the bottom:
+
+ Slot 1/ [red zone of 32 bytes called 'RIGHT RedZone
Jakub Jelinek ja...@redhat.com writes:
The bug is elsewhere, the following patch should fix this
(and I've reordered the assignments according to the call arg
number, so that it is more readable at the same time).
Ok for trunk?
2012-11-12 Jakub Jelinek ja...@redhat.com
* asan.c
Hello Jack,
Jack Howarth howa...@bromo.med.uc.edu writes:
Dodji,
I am finding that at r193442 bootstrapping on
x86_64-apple-darwin12 fails with...
../../../../gcc-4.8-20121112/libsanitizer/interception/interception_mac.cc:16:41:
fatal error: mach_override/mach_override.h: No such
Jakub Jelinek ja...@redhat.com writes:
On Sat, Nov 03, 2012 at 12:03:45AM +0100, Dodji Seketeli wrote:
+ int fallthrough_probability =
+then_more_likely_p
+? PROB_VERY_UNLIKELY
+: PROB_ALWAYS - PROB_VERY_UNLIKELY;
Just a formatting nit, I think = needs to go on the next line
Jakub Jelinek ja...@redhat.com writes:
On Thu, Nov 01, 2012 at 02:52:52PM -0700, Xinliang David Li wrote:
I think it is better to apply this patch to asan first to avoid extra
thread. You probably just need to retrieve your runtime part of the
trunk patch and resend it. Make sense?
Yeah,
[After multiple failed attempts at compressing this huge patch enough to
let it pass through the drastic mailing engine's 400KB size limit, I am
sending a link to the patch (at the end of this message) to let people
download it instead. Sorry for spamming the people in the CC list.]
This
Konstantin Serebryany konstantin.s.serebry...@gmail.com writes:
[A cultural question I've kept asking myself is Why has address
sanitizer authors called these red zones (LEFT, MIDDLE, RIGHT)
instead of e.g, (BOTTOM, MIDDLE, TOP). Maybe they can step up and
educate me so that I get less
Xinliang David Li davi...@google.com writes:
Changing the option is part of the plan.
Indeed.
Dodji, can you make the option change part of one the patches (e.g,
the first one that introduces it) -- there seems no need for a
separate patch for it.
Sure thing. I have done the change on my
Konstantin Serebryany konstantin.s.serebry...@gmail.com writes:
http://research.google.com/pubs/archive/37752.pdf
The horizontal drawing is given in section 3.3 and hence the redzones there
are called left/right.
The stack poisoning is only explained using an example in C.
Great, thanks.
Joseph S. Myers jos...@codesourcery.com writes:
On Thu, 1 Nov 2012, do...@redhat.com wrote:
From: dnovillo dnovillo@138bc75d-0d04-0410-961f-82ee72b054a4
Following a discussion we had on this list, this patch renames the
file tree-asan.* into asan.*.
* asan.c: Rename from
.
+ * tree-pass.h (pass_asan_O0): New declaration.
+
2012-10-11 Jakub Jelinek ja...@redhat.com
Dodji Seketeli do...@redhat.com
diff --git a/gcc/asan.c b/gcc/asan.c
index baaec0f..e7f4943 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -123,7 +123,7 @@ build_check_stmt (tree base
This patch implements the protection of stack variables.
To understand how this works, lets look at this example on x86_64
where the stack grows downward:
int
foo ()
{
char a[23] = {0};
int b[2] = {0};
a[5] = 1;
b[1] = 2;
return a[5] + b[1];
}
For this function, the stack
This patch implements the protection of global variables.
The basic idea is to insert a red zone between two global variables
and install a constructor function that calls the asan runtime to do
the populating of the relevant shadow memory regions at load time.
So the patch lays out the global
/asan.c | 36 +++-
2 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan
index a2e18ce..395ba4f 100644
--- a/gcc/ChangeLog.asan
+++ b/gcc/ChangeLog.asan
@@ -1,3 +1,8 @@
+2012-10-26 Dodji Seketeli do...@redhat.com
| 120 +
2 files changed, 81 insertions(+), 44 deletions(-)
diff --git a/gcc/ChangeLog.asan b/gcc/ChangeLog.asan
index 395ba4f..903dc52 100644
--- a/gcc/ChangeLog.asan
+++ b/gcc/ChangeLog.asan
@@ -1,5 +1,10 @@
2012-10-26 Dodji Seketeli
100644
--- a/gcc/ChangeLog.asan
+++ b/gcc/ChangeLog.asan
@@ -1,5 +1,23 @@
2012-10-26 Dodji Seketeli do...@redhat.com
+ * asan.c (insert_if_then_before_iter, instrument_mem_region_access,
+ (instrument_strlen_call, maybe_instrument_builtin_call,
+ (maybe_instrument_call): New
Instead of planning this change for the branch, would it be possible to
plan it for trunk directly, on top of the patches that I posted for
review there?
The patch could go in on top of the patches I posted.
Wei Mi w...@google.com writes:
This is the part2.
On Thu, Nov 1, 2012 at 1:02 PM,
Hello,
This message is just an excuse to kick off a discussion about how we
should proceed to prepare the merge of the AddressSanitizer branch
into trunk, as the not-yet known date of the stage1 closing seems to
be approaching fast now.
Here are some topics that I think would be interesting to
Jason Merrill ja...@redhat.com writes:
On 10/26/2012 01:37 PM, Dodji Seketeli wrote:
cp_next_tokens_can_be_std_attribute_p (cp_parser *parser)
{
- return cp_nth_tokens_can_be_std_attribute_p (parser, 1);
+ cp_token *token = cp_lexer_peek_token (parser-lexer);
+
+ return (cxx_dialect
Hello,
Consider this short example:
templatetypename T
struct X { };
templatetypename T
using Y = const XT;
using Z = Yint;
G++ crashes in lookup_class_template_1 while trying to build the alias
template instantiation Yint.
I think this is indirectly due to the fact
Jakub Jelinek ja...@redhat.com writes:
+ location_t location = gimple_location (call);
I'd call the var just loc, that is far more commonly used and shorter.
Done.
+ /* If we initially had an instruction like:
+
+ int n = strlen (str)
+
+ we now want to instrument the access
Hello,
In this PR, G++ embarrassingly fails to parse the simple alignas
expression below:
alignas(double) int f;
even though the simple-declaration production in Clause 7 suggests
otherwise.
Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
PR c++/54955
it should be that. I have updated the patch.
Jakub Jelinek ja...@redhat.com writes:
On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
Jakub Jelinek ja...@redhat.com writes:
For 'strlen', can the memory check be done at the end of the string
using the returned length?
Guess
Jakub Jelinek ja...@redhat.com writes:
+instrument_derefs (iter, dest, location, is_store);
BUILTIN_ATOMIC_LOAD* are just loads and so should clear is_store.
Done.
+ if (len != NULL_TREE)
+{
+ is_store = (dest != NULL_TREE);
+
+ if (source0 != NULL_TREE)
+
Jakub Jelinek ja...@redhat.com writes:
On Tue, Oct 23, 2012 at 03:08:07PM +0200, Dodji Seketeli wrote:
+static gimple_stmt_iterator
+create_cond_insert_point_before_iter (gimple_stmt_iterator *iter,
+ bool then_more_likely_p
Jakub Jelinek ja...@redhat.com writes:
On Tue, Oct 23, 2012 at 03:11:29PM +0200, Dodji Seketeli wrote:
+ /* (src, n) style memops. */
+case BUILT_IN_STRNDUP:
+ source0 = gimple_call_arg (call, 0);
+ len = gimple_call_arg (call, 1);
+ break;
I think you can't
Jakub Jelinek ja...@redhat.com writes:
For 'strlen', can the memory check be done at the end of the string
using the returned length?
Guess strlen is commonly expanded inline, so it would be worthwhile to check
the shadow memory after the call (well, we could check the first byte
before the
Jakub Jelinek ja...@redhat.com writes:
On Wed, Oct 24, 2012 at 05:16:26PM +0200, Dodji Seketeli wrote:
Jakub Jelinek ja...@redhat.com writes:
For 'strlen', can the memory check be done at the end of the string
using the returned length?
Guess strlen is commonly expanded inline, so
I am not a maintainer so the below are just some casual comments of
mine. I am deferring to the maintainers for a real review.
Manuel López-Ibáñez lopeziba...@gmail.com writes:
gcc/
* tree-diagnostic.c (maybe_unwind_expanded_macro_loc):
Use diagnostic_attach_note.
*
Hello,
The three patches following up this message implement instrumenting
memory access builtins calls in AddressSanitizer, like what the llvm
implementation does.
The first two patches do some factorizing that is used by the third
one. I have split them up like this to ease the review and to
This patch makes build_check_stmt accept its memory access parameter
to be an SSA name. This is useful for a subsequent patch that will
re-use.
Tested by running cc1 -fasan on the program below with and without the
patch and inspecting the gimple output to see that there is no change.
void
foo
This patch splits a new create_cond_insert_point_before_iter function
out of build_check_stmt, to be used by a later patch.
Tested by running cc1 -fasan on the test program below with and
without the patch and by inspecting the gimple output to see that
there is no change.
void
foo ()
{
char
This patch instruments many memory access patterns through builtins.
Basically, for a call like:
__builtin_memset (from, 0, n_bytes);
the patch would only instrument the accesses at the beginning and at
the end of the memory region [from, from + n_bytes]. This is the
strategy used by the
The C++ bits look good to my casual non-maintainer eyes. Let's CC
Jason.
Thanks.
Jonathan Wakely jwakely@gmail.com a écrit:
This adds a warning switch for the existing returning address of
local variable warnings in the C and C++ FEs which are enabled by
default but have no switch
Hello Manuel,
Let's CC Gaby on this one as well.
Manuel López-Ibáñez lopeziba...@gmail.com writes:
The problem is that the macro unwinder code is changing the original
diagnostic type and not restoring it, so the code detecting that we
ICE fails to abort, which triggers another ICE, and so
Hello,
While reading alias.c, it seemed to me that some comments could use
some cleanups.
OK for trunk?
Thanks.
gcc/
* alias.c: Cleanup comments.
---
gcc/alias.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/gcc/alias.c
Florian Weimer fwei...@redhat.com a écrit:
On 10/10/2012 06:02 PM, Dodji Seketeli wrote:
I just have one question for own education.
Regarding:
@@ -2450,7 +2450,13 @@
if (array_p TYPE_VEC_NEW_USES_COOKIE (elt_type))
size = size_binop (PLUS_EXPR, size, cookie_size
domi...@lps.ens.fr (Dominique Dhumieres) a écrit:
The following tests are failing (with -m32):
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors)
FAIL:
Hello Florian,
Let's CC Jason for this optimization patch.
Florian Weimer fwei...@redhat.com a écrit:
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.
I just have
Hello Dominique,
domi...@lps.ens.fr (Dominique Dhumieres) writes:
The following tests are failing (with -m32):
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors)
Jason Merrill ja...@redhat.com writes:
Let's move the alias template case from
primary_template_instantiation_p into alias_template_specialization_p
and call the latter from the former. And also call it from tsubst.
Like the below?
Note that I have changed the type of the argument of
Hello,
A couple of obj-c++ tests were failing[1] because the tokens '[[' can
either be the beginning of a c++11 attribute (that is itself at the
beginning of a statement), or the beginning of a nested
objc-message-expression. This patch resolves the ambiguity by
tentatively parsing the c++11
Hello,
The current implementation of C++11 attributes forbids them from being
applied to a type unless the type is being declared. I forgot to
adjust g++.dg/cpp0x/gen-attrs-{8,36,37}.C that was being run only on
ia32.
Fixed thus, tested on i386-unknown-linux-gnu and
x86_64-unknown-linux-gnu
Jason Merrill ja...@redhat.com writes:
OK.
Thanks. Committed to trunk at revision r192199.
--
Dodji
Diego Novillo dnovi...@google.com writes:
On 2012-10-02 05:45 , Richard Guenther wrote:
Anybody else with things they want to merge during stage1?
Finally, I've been thinking of porting asan/tsan to replace
mudflap. Dodji, you expressed interest in it recently.
Yes I did. A bit too
Jakub Jelinek ja...@redhat.com a écrit:
--- gcc/cp/call.c.jj 2012-09-27 12:45:49.0 +0200
+++ gcc/cp/call.c 2012-10-01 17:53:17.594609236 +0200
@@ -557,7 +557,10 @@ null_ptr_cst_p (tree t)
{
/* Core issue 903 says only literal 0 is a null pointer constant. */
Hello,
Consider this invalid example given in the PR, where T is not defined:
1 templatetypename
2 struct X {
3 using type = T;
4 };
g++ yields the confusing diagnostics:
test.cc:3:10: error: expected nested-name-specifier before 'type'
using type = T;
Jason Merrill ja...@redhat.com writes:
On 09/20/2012 10:01 AM, Dodji Seketeli wrote:
This is because in cplus_decl_attributes, save_template_attributes
makes so that the 'unused' attribute is applied to its appertaining
entity only at instantiation time. But then at parsing time
Hello,
In the example of the patch, g++ fails to warn that the variable N::i
(introduced via a using declaration) is unused.
This is because as we want to emit the warning in poplevel, when we
walk the local bindings returned by getdecls, we forget that a
VAR_DECL introduced by a using
Hello,
Consider this example:
1 templateclass...I struct List {};
2 templateint T struct Z {static const int value = T;};
3 templateint...T using LZ = ListZT...;
4
5 templateclass...U
6 struct F
7 {
8using N = LZU::value...; //#1 This should
Hello,
We don't record the use of a typedef when it's used through a
typename. So on the example of the patch, g++ complains that the 'type'
typedef is not used. Fixed thus.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* decl.c (make_typename_type): Record the use of
Let's CC Jason.
---BeginMessage---
Hello,
I've been investigating a bug in gcc I came across recently and after some
difficulties, I have produced a patch that actually fixes that behavior.
However, I don't think the patch is very good and I would really
appreciate your help in making it
PING^2.
Dodji Seketeli do...@redhat.com writes:
Hello,
Consider this short test snippet:
-8---
#define STRINGIFY(x) #x
#define TEST(x) \
_Pragma(STRINGIFY(GCC diagnostic ignored -Wunused-local-typedefs)) \
typedef int myint
Gabriel Dos Reis g...@integrable-solutions.net writes:
I think we show the stack not just for errors, but for any diagnostics.
I agree, FWIW.
--
Dodji
Hello,
While working on something else, I noticed that debug_tree (vec), when
vec is a TREE_VEC, was crashing because TREE_NOTHROW was asserting that
its argument is not a TREE_VEC, so print_node would crash.
It turned out that TREE_NOTHROW was accidentally modified by this
change set:
commit
Hello Jiří,
I think this question should be directed at gcc-h...@gcc.gnu.org.
Please send any response to this email there.
Jiří Paleček jpale...@web.de a écrit:
I tried to run make check-c++ from the top directory of the source
code.
Quoted from http://gcc.gnu.org/install/configure.html:
Dimitrios Apostolou ji...@gmx.net a écrit:
[...]
* include/libiberty.h (XOBDELETE, XOBGROW, XOBGROWVEC, XOBSHRINK)
(XOBSHRINKVEC, XOBFINISH): New type-safe macros for obstack
operations.
(XOBFINISH): Changed to return (T *) instead of T. All callers
updated.
Hello,
In the example of this problem report, during the substituting of int
into 'function', tsubst_aggr_type fails for the alias ctxt1. This is
because TYPE_TEMPLATE_INFO looks for the TEMPLATE_INFO of the ctxt1
alias at the wrong place and was wrongly finding it to be NULL.
Namely, it was
Dehao Chen de...@google.com writes:
Index: libcpp/line-map.c
[...]
+ /* Data structure to associate an arbitrary data to a source location. */
+ struct location_adhoc_data {
+ source_location locus;
+ void *data;
+ };
+
+ /* The following data structure encodes a location with some
Hello Diego,
Just some minor comments.
Diego Novillo dnovi...@google.com a écrit:
[...]
+@section User-provided marking routines for template types
+When a template type @code{TP} is marked with @code{GTY}, all
+instances of that type are considered user-provided types. This means
+that
Hello Yunfeng,
Thank you for following up, and sorry for me reviewing your patches so
lately. The libcpp changes are coming along nicely, IMHO. I like the
fact that they are getting pretty minimal. I just have a few mostly
cosmetic comments at this point.
[...]
diff -cpr
Hello Dehao,
I have mostly cosmetic comments to make about the libcpp parts.
Dehao Chen de...@google.com writes:
Index: libcpp/include/line-map.h
===
*** libcpp/include/line-map.h (revision 189835)
--- libcpp/include/line-map.h
Andrew Hughes ahug...@redhat.com writes:
OK.
As this is a GNU Classpath change, it should go in there first to avoid
creating
a divergence which will cause later problems in merging. Classpath is
regularly
merged into gcj as a whole.
I found several patches during the last merge
Andrew Hughes ahug...@redhat.com writes:
Don't worry about reverting it. I'll add it to Classpath now, then
they'll be in sync when we do the next merge.
Thank you.
In future, please post changes to files under the libjava/classpath directory
to
classp...@gnu.org and feel free to ping me
Hello,
This is a fix to prepare the xmlj_io.c file of gnu classpath to a coming
API change in libxml2.
Basically, we were previously accessing fields inside the
xmlOutputBuffer struct of libxml2. In a coming version of libxml2,
that won't be possible anymore. Client code will have to use
When working on something else, I noticed that failing to provide the
second argument to the static_assert operator would lead to an ICE.
Fixed thus, and tested against trunk on x86_64-unknown-linux-gnu.
gcc/cp/
* semantics.c (finish_static_assert): Don't crash on erroneous
Hello,
Sandeep Soni soni.sande...@gmail.com a écrit:
Hi Diego,
The following patch recognizes function declarations. I am now trying
to create a gimple sequence of all the statements within the function
body.
The chagelog is as follows:
2012-07-31 Sandeep Soni soni.sande...@gmail.com
Hello,
Ryan Mansfield rmansfi...@qnx.com a écrit:
On 12-07-19 06:06 PM, Gabriel Dos Reis wrote:
[...]
Would moving the GCC_DRIVER_HOST_INITIALIZATION after diagnostic_initialize
be OK?
yes, I think so.
OK, then here's a changelog entry for the diff.
2012-07-20 Ryan Mansfield
Gabriel Dos Reis g...@integrable-solutions.net a écrit:
2012-07-20 Ryan Mansfield rmansfi...@qnx.com javascript:;
* gcc.c (main): Move GCC_DRIVER_HOST_INITIALIZATION after
diagnostic_initialize.
Could someone please apply the change?
The change seems small and
201 - 300 of 599 matches
Mail list logo
