On Fri, Jan 13, 2012 at 12:01 AM, Eric Botcazou wrote:
>> The solution is to fix the scanning loop to look into the insn pattern
>> itself for all set and clobbered hard registers. This way, all
>> registers, clobbered by the pattern, will be correctly marked in the
>> "live" bitmap, including FLA
Hi Tobias,
On Thu, 12 Jan 2012, Tobias Burnus wrote:
I intent to commit the attached patch to link
I believe Benjamin committed this yesterday, right? Thanks for
raising the issue, these links are good to have.
Gerald
> Yes, it is a complete solution. Tracking register liveness is
> different issue, and a register is indeed dead after instruction, if
> it has been clobbered by insn, or when marked unused.
My concern was liveness within the new sequence of instructions: suppose you
have
(set (reg:M x) (...))
Denis Chertykov wrote:
> Georg-Johann Lay:
>> Denis Chertykov schrieb:
>>
>> 2) Can we remove from avr.c:avr_option_override() the following:
>>
>> if (avr_strict_X)
>> flag_caller_saves = 0;
>>
>> that hacked around similar spill fails?
>>
>> 3) As PR50775 is fixed: Would it make sense to
On Fri, Jan 13, 2012 at 10:00 AM, Eric Botcazou wrote:
>> Yes, it is a complete solution. Tracking register liveness is
>> different issue, and a register is indeed dead after instruction, if
>> it has been clobbered by insn, or when marked unused.
>
> My concern was liveness within the new sequen
On Fri, Jan 13, 2012 at 12:09 AM, DJ Delorie wrote:
>
> Another case where one address space may support multiple pointer
> sizes, so conversions between such must be preserved.
>
> * tree-ssa.c (useless_type_conversion_p): Conversions between
> different-sized pointers aren't useles
This is again a test case that assumes sizeof (int) > 2 which is not true in
general.
* g++.dg/ipa/pr51759.C: Fix assumption sizeof(int) > 2.
Ok for trunk.
Index: testsuite/g++.dg/ipa/pr51759.C
===
--- testsuite/g++.dg/ipa
Hi Gerald,
On 01/13/2012 09:28 AM, Gerald Pfeifer wrote:
On Thu, 12 Jan 2012, Tobias Burnus wrote:
I intent to commit the attached patch to link
I believe Benjamin committed this yesterday, right? Thanks for
raising the issue, these links are good to have.
Yes - albeit as last item of Cave
Uros Bizjak writes:
> On Fri, Jan 13, 2012 at 10:00 AM, Eric Botcazou wrote:
>>> The problem my patch solves is the answer to the question "Is the
>>> choosen non-live temporary register untouched over the insn
>>> sequence?". The answer: "Yes, if it was not set or clobbered by any
>>> insn in th
This fixes the ICEs that occur with redeclared extern inline functions
in some circumstances. It avoids the cgraph confusion by _not_ merging
the two decls in this case but simply drops the old (extern inline)
one on the floor. This causes the cgraph to be properly presented
with two different d
This fixed multi-char testcase that would otherwise lead to "constant exceeds
its type" message and thus FAIL.
Use 2-letter constant is sufficient and don't break on int=16 platforms.
Ok to apply?
Johann
* gcc.dg/cpp/warn-multichar-2.c: Fix to work on int=16 platforms.
Index: gcc.dg/cp
Similar to fix for gcc.dg/cpp/warn-multichar-2.c: It's sifficient to have a
2-letter constant.
Ok to apply?
Johann
* gcc.dg/cpp/warn-multichar.c: Fix to work on int=16 platforms.
Index: gcc.dg/cpp/warn-multichar.c
===
---
Hi,
2012/1/7 Gerald Pfeifer :
> On Thu, 29 Dec 2011, Fabien Chêne wrote:
>> As previously announced, here is a patch that deprecate access
>> declarations . I did a little tour in the GCC museum old-deja --and in
>> g++.dg as well -- to disinter and adjust those dusty tests. To avoid
>> false posi
Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does not.
Ok for trunk?
Johann
* gcc.dg/debug/dwarf2/pr49871.c: Fix to work on int16 platforms.
Index: gcc.dg/debug/dwarf2/pr49871.c
===
--- gcc.dg/debug
Hello!
> I have committed a patch to libgo to update it to the weekly.2011-12-22
> release. As usual I am not including all the changes here, only the
> ones to files which are specific to gccgo. Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
After this
This fixes the PR by making sure to use RSO for calls to nested
functions that return variable-sized types. This is necessary
because GIMPLE cannot handle calls with an embedded assignment
of variable size (we can't put the WITH_SIZE_EXPR anywhere) and
thus we would ICE later when not using RSO.
On Jan 13, 2012, at 10:30 AM, Richard Guenther wrote:
> On Fri, Jan 13, 2012 at 12:09 AM, DJ Delorie wrote:
>>
>> Another case where one address space may support multiple pointer
>> sizes, so conversions between such must be preserved.
>>
>>* tree-ssa.c (useless_type_conversion_p): Co
Hi,
PR48308 is a case where on the ARM port we incorrectly delete a call
to strcmp assuming that this is dead. However the problem starts early
enough in combine where when try_combine is given i2 of the form
(parallel [(set (reg:CC X) (compare:CC OP (const_int 0)))
(set Y O
http://gcc.gnu.org/viewcvs?view=revision&revision=183151
As explained in its comment, the test case works only if BRANCH_COST > 1.
This is done by the patch.
* gcc.dg/pr46309.c: Set branch cost to greater 1 for avr.
--- trunk/gcc/testsuite/gcc.dg/pr46309.c2012/01/13 05:11:45
On 01/13/2012 10:58 AM, Richard Sandiford wrote:
> Yes, because new test ALWAYS includes the registers that were wrongly
> marked as dead by previous test due to REG_UNUSED and noclobber
> processing.
Or to put it another way: the insn-to-insn changes in the current liveness
sets are all prod
This fixes PR37985 where since
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
mark conversions produced by convert_to_integer with TREE_NO_WARNING.
This may shadow "real" stmts with no effects, thus we should
simply strip them again before checking for TREE_SIDE_EFFECTS.
Bootstrap &
2012/1/13 Georg-Johann Lay :
> Denis Chertykov wrote:
>> Georg-Johann Lay:
>>> Denis Chertykov schrieb:
>>>
>>> 2) Can we remove from avr.c:avr_option_override() the following:
>>>
>>> if (avr_strict_X)
>>> flag_caller_saves = 0;
>>>
>>> that hacked around similar spill fails?
>>>
>>> 3) As
On Fri, 13 Jan 2012, Richard Guenther wrote:
>
> This fixes the ICEs that occur with redeclared extern inline functions
> in some circumstances. It avoids the cgraph confusion by _not_ merging
> the two decls in this case but simply drops the old (extern inline)
> one on the floor. This causes
This patch adds -Wno-pointer-to-int-cast to the options in order to avoid FAIL
because of "warning: cast from pointer to integer of different size" when
sizeof(void*) = 2.
* gcc.dg/pr50527.c: Don't FAIL if sizeof(void*) = 2
Index: gcc.dg/pr50527.c
Following test case has wrong prototypes of malloc/memset and this is the fix.
* gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy.
Index: gcc.dg/lto/20090218-2_1.c
===
--- gcc.dg/lto/20090218-2_1.c (revision 18315
This test case is obviously written for 32-bit platforms, thus added
"dg-require-effective-target ilp32" to ensure that the pointer mess won't lead
to FAILs because of
warning: cast to pointer from integer of different size
and
warning: cast from pointer to integer of different size
Ok to apply
Dear all,
the front end uses for array indices (gfc_index_integer_kind /
gfc_array_index_type) which is a signed integer of size POINTER_SIZE.
The libgfortran library used to use
typedef ssize_t index_type;
which fails if sizeof(void*) is not sizeof(ssize_t); the latter is the
case on LP64
Denis Chertykov wrote:
> Committed
>
> Denis
Consider code prom PR51374
void __vector_18 (void)
{
extern char slot;
unsigned char status = (*(volatile unsigned char*) 0x2B);
unsigned char data = (*(volatile unsigned char*) 0x2C);
if (status & 0x10)
slot = 0;
}
the cod
> I went ahead and created a small patch with the changes above which
> is the second patch below and committed it. If you'd like to see
> some changes, just let me know.
Thanks Gerald! This looks good.
For the links, I just tried to add them where they'd been added before.
Seems reasonable
Dear All,
When the only modification was to set the attribute alloc_comp for
class containers, I was going to commit this patch as obvious.
However, it caused a regression in class-19.f03 by increasing the
count of BUILTIN_FREE from 11 to 23! Whilst the extra calls did no
harm, this offended my s
On Fri, Jan 13, 2012 at 16:07, Tobias Burnus wrote:
> Dear all,
>
> the front end uses for array indices (gfc_index_integer_kind /
> gfc_array_index_type) which is a signed integer of size POINTER_SIZE.
>
> The libgfortran library used to use
> typedef ssize_t index_type;
> which fails if sizeof
Making a thunk to a deleted virtual function was making G++ very
confused. Fixed by using __cxa_deleted_virtual for deleted virtual
functions, as specified by the ABI.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 2bf4059b4ebc1c1966b7b4ba94f520f7c0022ca0
Author: Jason Merrill
Date:
On 01/13/2012 04:29 PM, Paul Richard Thomas wrote:
Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk?
OK. Thanks for the patch!
Good that we have __builtin_free counting test cases, which helps to
detect such issues.
Tobias
2012-01-12 Paul Thomas
PR fortran/48351
On Jan 13, 2012, at 2:07 AM, Georg-Johann Lay wrote:
> This fixed multi-char testcase that would otherwise lead to "constant exceeds
> its type" message and thus FAIL.
>
> Use 2-letter constant is sufficient and don't break on int=16 platforms.
>
> Ok to apply?
Ok.
On Jan 13, 2012, at 2:10 AM, Georg-Johann Lay wrote:
> Similar to fix for gcc.dg/cpp/warn-multichar-2.c: It's sifficient to have a
> 2-letter constant.
>
> Ok to apply?
Ok.
Dear all,
seemingly may (potential) users still do not realize that gfortran's
multi-image coarray support is not yet usable as only the basic libcaf
infrastructure (registering, deregistering, argument passing, syncing,
start up/close down, error stop - and all the coindex handling routines)
On Fri, Jan 13, 2012 at 11:05:36AM +0100, Richard Guenther wrote:
> This fixes the ICEs that occur with redeclared extern inline functions
> in some circumstances. It avoids the cgraph confusion by _not_ merging
> the two decls in this case but simply drops the old (extern inline)
> one on the flo
On Jan 13, 2012, at 2:16 AM, Georg-Johann Lay wrote:
> Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does not.
Fixed as obvious is usually the term we use when work is checked in.
> Ok for trunk?
Ok for trunk is the term we use for work that hasn't been checked in. So, I'm
On Jan 13, 2012, at 4:01 AM, Georg-Johann Lay wrote:
> This patch adds -Wno-pointer-to-int-cast to the options in order to avoid FAIL
> because of "warning: cast from pointer to integer of different size" when
> sizeof(void*) = 2.
Ok.
> * gcc.dg/pr50527.c: Don't FAIL if sizeof(void*) = 2
On Jan 13, 2012, at 4:20 AM, Georg-Johann Lay wrote:
> Following test case has wrong prototypes of malloc/memset and this is the fix.
>
> * gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy.
[ be sure to add Ok? to patches you didn't check in, it is easy for me to think
you applie
On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote:
> This test case is obviously written for 32-bit platforms, thus added
> "dg-require-effective-target ilp32" to ensure that the pointer mess won't lead
> to FAILs because of
>
> warning: cast to pointer from integer of different size
>
> and
>
On Fri, 13 Jan 2012, Richard Guenther wrote:
> This fixes PR37985 where since
> http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> mark conversions produced by convert_to_integer with TREE_NO_WARNING.
> This may shadow "real" stmts with no effects, thus we should
> simply strip them aga
> 2011-02-25 Rainer Orth
>
> PR target/47852
> * configure.host (irix6.5*): Add -lpthread to OPT_LDFLAGS.
>
OK
-benjamin
Hi,
the stack-var conflict generation code needs 13 (out of 34) seconds, with
-O0 on the second testcase of PR46590. Most of the time is spent in
generating the same conflicts again and again at each basic block (the
time right now is O(nr-of-bbs * N^2) where the number of conflicts is
O(N^2)
On Fri, Jan 13, 2012 at 09:12:25AM -0800, Mike Stump wrote:
> On Jan 13, 2012, at 2:16 AM, Georg-Johann Lay wrote:
> > Fixed as obvious as 1 << 15 fits always inside an int whereas 1<<16 does
> > not.
>
> Fixed as obvious is usually the term we use when work is checked in.
>
> > Ok for trunk?
>
Mike Stump writes:
> On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote:
>> This test case is obviously written for 32-bit platforms, thus added
>> "dg-require-effective-target ilp32" to ensure that the pointer mess won't
>> lead
>> to FAILs because of
>>
>> warning: cast to pointer from integ
On Jan 13, 2012, at 1:42 AM, Georg-Johann Lay wrote:
> This is again a test case that assumes sizeof (int) > 2 which is not true in
> general.
>
> * g++.dg/ipa/pr51759.C: Fix assumption sizeof(int) > 2.
>
> Ok for trunk.
Ok.
LGTM
On Thu, Jan 12, 2012 at 3:16 PM, wrote:
>
> Reviewers: xur, shenhan, jingyu,
>
> Message:
> This merges in the fix for ICE when using PGO when building Chrome.
>
>
>
> Please review this at http://codereview.appspot.com/5541046/
>
> Affected files:
> M .
> M gcc/ChangeLog.google-4_
For PR 35688 I fixed the compiler to reduce the visibility of a template
instantiation based on the visibility of its template arguments. As a
result of this, we seem to have started marking some external symbols as
.hidden because:
1) One of the template arguments is hidden, so the instantia
On Jan 13, 2012, at 9:23 AM, Rainer Orth wrote:
> Mike Stump writes:
>
>> On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote:
>>> This test case is obviously written for 32-bit platforms, thus added
>>> "dg-require-effective-target ilp32" to ensure that the pointer mess won't
>>> lead
>>> to FA
Uros Bizjak writes:
>> I have committed a patch to libgo to update it to the weekly.2011-12-22
>> release. As usual I am not including all the changes here, only the
>> ones to files which are specific to gccgo. Bootstrapped and ran Go
>> testsuite on x86_64-unknown-linux-gnu. Committed to mai
Hi,
in C++11 mode after erroring out for an undeclared name we can easily
end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which
has error_mark_node as argument.
The latter trees are currently completely unhandled by
cxx_eval_constant_expression, thus in order to avoid such IC
Ian Lance Taylor writes:
> I have committed a patch to libgo to update it to the weekly.2011-12-22
> release. As usual I am not including all the changes here, only the
> ones to files which are specific to gccgo. Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu. Committed to ma
On Fri, Jan 13, 2012 at 7:00 PM, Ian Lance Taylor wrote:
> Uros Bizjak writes:
>
>>> I have committed a patch to libgo to update it to the weekly.2011-12-22
>>> release. As usual I am not including all the changes here, only the
>>> ones to files which are specific to gccgo. Bootstrapped and ra
Mike Stump wrote:
> On Jan 13, 2012, at 9:23 AM, Rainer Orth wrote:
>> Mike Stump writes:
>>
>>> On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote:
This test case is obviously written for 32-bit platforms, thus added
"dg-require-effective-target ilp32" to ensure that the pointer mess w
Mike Stump wrote:
> On Jan 13, 2012, at 4:20 AM, Georg-Johann Lay wrote:
>> Following test case has wrong prototypes of malloc/memset and this is the
>> fix.
>>
>> * gcc.dg/lto/20090218-2_1.c: Fix prototype of malloc, memcpy.
>
> [ be sure to add Ok? to patches you didn't check in, it is eas
On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote:
> The ilp32 is the closes match:
>
> The source casts pointer to int, int to pointer, long to int, uses 32-bit
> initializers for int, assumes size_t is unsigned long any maybe others.
No. The source is just fine for any target wh
Jakub Jelinek wrote:
> On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote:
>> The ilp32 is the closes match:
>>
>> The source casts pointer to int, int to pointer, long to int, uses 32-bit
>> initializers for int, assumes size_t is unsigned long any maybe others.
>
> No. The source
On 01/13/2012 01:16 PM, Paolo Carlini wrote:
in C++11 mode after erroring out for an undeclared name we can easily
end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which
has error_mark_node as argument.
We should never pass uninstantiated trees to
cxx_eval_constant_expression; t
On Fri, Jan 13, 2012 at 08:25:39PM +0100, Georg-Johann Lay wrote:
> So it's fine to dump any code to the test suite no matter on what platform it
> might break or work?
It is wrong to knowingly commit testcases that break on such platforms,
but you really shouldn't expect every committer to test a
Here the issue is that in some cases the compiler warns about control
reaching the end of the function when a return is followed by a break.
In the audit trail people noted that the C front end worked around this
issue with
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01452.html
and I've j
Jakub Jelinek wrote:
> On Fri, Jan 13, 2012 at 08:25:39PM +0100, Georg-Johann Lay wrote:
>> So it's fine to dump any code to the test suite no matter on what platform it
>> might break or work?
>
> It is wrong to knowingly commit testcases that break on such platforms,
> but you really shouldn't e
Good day, my friend!
Love means to commit oneself without guarantee, to give oneself completely
in the hope that our love will produce love in the loved person. Love is
an act of faith, and whoever is of little faith is also of little love.
I don?t doubt even for a single second that I will be al
Committed as revision 183162.
Thanks Tobias - I'll look at yours first thing tomorrow.
Paul
On Fri, Jan 13, 2012 at 4:50 PM, Tobias Burnus wrote:
> On 01/13/2012 04:29 PM, Paul Richard Thomas wrote:
>>
>> Bootstrapped and regtested on i686/Ubuntu10.04 - OK for trunk?
>
>
> OK. Thanks for the pa
On Jan 13, 2012, at 11:25 AM, Georg-Johann Lay wrote:
> So it's fine to dump any code to the test suite no matter on what platform it
> might break or work?
No. It isn't fine, but it does happen. Some people spend a lot of time,
trying to get the testcases minimal, portable and correct. Other
Hi,
On 01/13/2012 01:16 PM, Paolo Carlini wrote:
in C++11 mode after erroring out for an undeclared name we can easily
end up calling cxx_eval_constant_expression on a CAST_EXPR etc, which
has error_mark_node as argument.
We should never pass uninstantiated trees to
cxx_eval_constant_expressi
Hi,
the attached patch changes the binding labels that are needed for
bind(C) symbols to be heap allocated rather than, as currently, being
fixed size arrays of size 127 (or 64 in module.c!?). There are two
benefits of this:
1) For the vast majority of symbols which are not bind(C) symbols in a
t
Hello,
Nothing fancy, just remove an odd couple of #includes that are not necessary.
OK for trunk?
Ciao!
Steven
gcc/
* c-decl.c: Do not include tree-mudflap.h
* tree-optimize.c: Likewise.
cp/
* decl2.c: Do not include tree-mudflap.h
* semantics.c: Likewise.
gcc/
On Fri, 13 Jan 2012, Steven Bosscher wrote:
> Hello,
>
> Nothing fancy, just remove an odd couple of #includes that are not necessary.
> OK for trunk?
OK with dependencies updated in Makefile.in.
--
Joseph S. Myers
jos...@codesourcery.com
Attached patch applied.
2012-01-13 François Dumont
* include/bits/hashtable_policy.h (_Hash_node_base): New, use it as
base class of ...
(_Hash_node, _Hash_node): ... those.
* include/bits/hashtable.h (_Hashtable): Replace
_M_begin_bucket_index
by _M_b
> That should not be necessary as there is a mode check below. Do you
> hit the issue only when the VOID_TYPE_P check is true? In that case
> simply delete it - it has become obsolete.
That seems to be happening, yes, but there are other checks
that might let differing modes through...
/* Ch
A patch I have developed for PR 50012 issues a warning for some code in
ipa-cp.c in which a variable of type int is compared to the return value
of VEC_length, which is unsigned int. This should logically require a
type cast, and actually I'm not sure why the warning is not issued
without my patch
I forgot to update the copyright year in the patch I just committed.
This patch corrects that omission. I did not bother with a separate
ChangeLog entry for this patch, since I think it is implicitly covered
by the ChangeLog entry I just committed. Sorry for omitting this
earlier.
Ian
Index: ip
PR c++/50012 shows a case where we do not issue a -Wsign-compare warning
when we should. I introduced this problem here:
2009-06-25 Ian Lance Taylor
* call.c (avoid_sign_compare_warnings): New static function.
(build_new_op): Call it.
* typeck.c (cp_build_binary_op): D
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> I have committed a patch to libgo to update it to the weekly.2011-12-22
>> release. As usual I am not including all the changes here, only the
>> ones to files which are specific to gccgo. Bootstrapped and ran Go
>> testsuite on x86_64-unknow
Uros Bizjak writes:
> On Fri, Jan 13, 2012 at 7:00 PM, Ian Lance Taylor wrote:
>
>> Thanks for the report, but this is surprising. Doesn't Alpha GNU/Linux
>> define TIOCGWINSZ in /usr/include/asm-generic/ioctls.h? And isn't that
>> file #include'd, indirectly, by ?
>>
>> If not, does Alpha GNU
Hello Everyone,
I just updated the copyright year in all the cilkplus specific
files in the Cilkplus branch. I also corrected a wordwrap problem in
one of the files. Here is the patch for what I updated.
Thanks,
Balaji V. Iyer.
Index: pragma_simd.c
===
David Daney writes:
> As discussed several months ago, libgo will not run on mips because it
> references the x86 specific system calls iopl() and ioperm(). These
> system calls do not exist in mips*-linux, so we move them to new
> 368/amd64 specific libcall_linux_*.go files.
>
> The attached pa
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
> Hi there,
>
> please find attached the patch and the Changelog entry for our work on
> the fortran bug #48426.
>
> The attached patch implements the options
>
> -finteger-4-integer-8
> -freal-4-real-8
> -freal-4-real-10
> -frea
On Wed, 2012-01-11 at 08:09 +1100, Richard Henderson wrote:
> On 01/11/2012 12:43 AM, Torvald Riegel wrote:
> >> One could steal code from bohem-gc for this.
> >> See GC_get_stack_base in os_dep.c.
> >
> > Thanks for the pointer. I looked at this code, and it seems fairly
> > complex given the de
When rolling back the undo log, the previous code restored the previous
data values but didn't actually truncate the undo log. So, on the next
restart of the transaction, we would be growing the undo log and
performing old undos again, leading to data corruption.
Committed to trunk as obvious.
co
On 01/13/2012 05:48 PM, Ian Lance Taylor wrote:
* typeck.c (enum_cast_to_uint): New static function.
Shouldn't this be "enum_cast_to_int", since the promotion is to
integer_type_node? OK with that change.
Jason
Here's the final patch, with testcase. Bootstrapped and tested on
x86_64 with no regressions.
I'm not sure of the rules here -- since this patch was in process
before Stage 3 closed, is it OK for 4.7? Or do I need to hold this
until Stage 1 opens for 4.8?
-cary
gcc/ChangeLog:
PR debug/
While looking at the -fmem-stats results for this testcase, I noticed
about 500MB of overhead coming from the VEC_safe_push in
cp_lexer_new_main. This is happening because when we allocate space for
a vector, the allocator pads it out some, and that space ends up lost.
The first patch changes
On 01/13/2012 03:57 PM, Paolo Carlini wrote:
Anyway, the reason we are not tsubst-ing such trees - eg, a CAST_EXPR on
a single element TREE_LIST as argument, with error_mark_node as value -
is that potential_constant_expression is false in
fold_non_dependent_expr_sfinae, thus tsubst_copy_and_buil
2012/1/13 Georg-Johann Lay :
> Denis Chertykov wrote:
>
>> Committed
>>
>> Denis
>
>
> Consider code prom PR51374
>
> void __vector_18 (void)
> {
> extern char slot;
> unsigned char status = (*(volatile unsigned char*) 0x2B);
> unsigned char data = (*(volatile unsigned char*) 0x2C);
>
>
86 matches
Mail list logo
