Hi!
This patch on top of the
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00500.html
patch adds multiplication overflow checking for the missing cases (modes
which don't have 2x wider supported mode so we can't do a widening multiply
to the wider mode or full wider mode multiplication, but we at l
On Sat, Dec 14, 2013 at 02:38:31AM +0100, Marek Polacek wrote:
> I noticed this bug a while ago on ppc64 and now I reproduced it even
> on x86_64 with -m32. The problem was that we were using add_optab even
> when dealing with MINUS_EXPR; we should use sub_optab instead.
>
> Regtested on x86_64-l
Hi Janus,
This review bounced of gnu-central because it had mime content - back
to plain text!
I am somewhat startled that this was so "easy" to fix (ie. the patch
looks easy but I'll bet that find the fix was not!).
OK for trunk. I think that MOD_VERSION does need bumping but I would
bow to go
This was causing the final pattern to not match. Committed.
* config/rl78/rl78-expand.md (one_cmplqi2): Make constant signed.
Index: config/rl78/rl78-expand.md
===
--- config/rl78/rl78-expand.md (revision 205980)
+++ confi
I noticed this bug a while ago on ppc64 and now I reproduced it even
on x86_64 with -m32. The problem was that we were using add_optab even
when dealing with MINUS_EXPR; we should use sub_optab instead.
Regtested on x86_64-linux (with both -m32/-m64), ok for trunk?
2013-12-14 Marek Polacek
On Dec 13, 2013, at 1:59 PM, DJ Delorie wrote:
> I went through all the patterns in the msp430 backend and converted
> all those that are volatile-safe to allow volatile MEM operands.
> Committed.
>
> * config/msp430/msp430.md (movqi): replace general_operand with
> msp_general_operan
On Fri, 2013-12-13 at 10:38 +0100, Richard Biener wrote:
> Apart from the issues raised by Trevor I want to question if we want
> to transition
> to STL-like iterators (yeah, I know, the gsi_ ones are already
> similar).
I think it's easier to read and -- more importantly -- understand
"foreign"
Rainer Orth writes:
> Andreas Schwab writes:
>
>> Rainer Orth writes:
>>
>>> diff --git a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>>> b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>>> --- a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>>> +++ b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.ex
I went through all the patterns in the msp430 backend and converted
all those that are volatile-safe to allow volatile MEM operands.
Committed.
* config/msp430/msp430.md (movqi): replace general_operand with
msp_general_operand and nonimmediate_operand with
msp_nonimmediat
> The patch is okay, but if other architecture maintainers could add
> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
Thanks, committed as rev. 205975
Adding other systems to the list of checks will be easy, once the maintainers
confirm that they want to opt in into i
On 12/13/2013, 4:02 PM, Jakub Jelinek wrote:
On Fri, Dec 13, 2013 at 03:48:25PM -0500, Vladimir Makarov wrote:
2013-12-12 Vladimir Makarov
* ira.h (struct ira_reg_equiv): Rename to ira_reg_equiv_s.
* ira.c: Ditto.
* lra-int.h (lra_init_equiv): New prototype.
On Fri, Dec 13, 2013 at 03:48:25PM -0500, Vladimir Makarov wrote:
> 2013-12-12 Vladimir Makarov
>
> * ira.h (struct ira_reg_equiv): Rename to ira_reg_equiv_s.
> * ira.c: Ditto.
> * lra-int.h (lra_init_equiv): New prototype.
> * lra-constraints.c (lra_init_equiv,
On Thu, 2013-12-12 at 03:13 -0500, Trevor Saunders wrote:
> On Wed, Dec 11, 2013 at 06:47:37PM +0100, Oleg Endo wrote:
> > On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
> > > Declaring the edge_iterator inside the for() is not a good argument
> > > against FOR_EACH_EDGE. Of course, brow
The following patch should fix arm test regressions after committing sp
elimination patch.
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 205974.
2013-12-12 Vladimir Makarov
* ira.h (struct ira_reg_equiv): Rename to ira_reg_equiv_s.
* ira.c: Ditto.
I'm fixing something completely unrelated, and noticed this...
Perhaps I'm missing something, but why do we need a gate when it always
returns true? Now that we have this `pass_data' business, we can set
has_gate to false.
I also fixed a minor typo in a comment.
Tested on x86-64 Linux.
OK?
Here are some soft merge conflict resolutions….
I've checked them in to fix the build.
Ok?
Index: ChangeLog.wide-int
===
--- ChangeLog.wide-int (revision 205969)
+++ ChangeLog.wide-int (working copy)
@@ -524,6 +524,7 @@
(a
committed as revision 205970 as obvious.
kenny
Index: gcc/genmodes.c
===
--- gcc/genmodes.c (revision 205967)
+++ gcc/genmodes.c (working copy)
@@ -891,7 +891,7 @@ emit_max_int (void)
max = i->bytesize;
if (max > mmax)
m
> Unfortunately, the g++.dg/cilk-plus testsuite repeated many of the
> errors that have already been fixed in its gcc.dg counterpart: not
> properly setting ld_library_path (setting instead of appending, which
> causes all 64-bit tests to FAIL on Solaris 10/x86) and using
> ALWAYS_CFLAGS (leads to
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
> Sent: Friday, December 13, 2013 12:40 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; 'gcc-patches@gcc.gnu.org'
> Subject: Re: [PING]: [GOMP4] [PATCH] SIMD-Enabl
Andreas Schwab writes:
> Rainer Orth writes:
>
>> diff --git a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>> b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>> --- a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>> +++ b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
>> @@ -25,10 +25,11 @@ if { !
Rainer Orth writes:
> diff --git a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
> b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
> --- a/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
> +++ b/gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp
> @@ -25,10 +25,11 @@ if { ![check_effective_target_cilkplus]
+ /* Two CPP_EOF token is added as a safety-net since the normal C
+ front-end has two token look-ahead. */
"Two CPP_EOF tokens are added"... Also, "safety net" are two words, not
one hyphenated one.
Otherwise, I'm fine with the present patch. It's up to Jakub or another
global revie
On 12/13/2013 10:58 AM, David Malcolm wrote:
{
gimple stmt = SSA_NAME_DEF_STMT (x);
@@ -2162,7 +2162,7 @@ chain_of_csts_start (struct loop *loop, tree x)
if (gimple_code (stmt) == GIMPLE_PHI)
{
if (bb == loop->header)
- return stmt;
+ return stmt->as_a_gimple_p
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Thursday, December 12, 2013 3:29 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; 'gcc-patches@gcc.gnu.org'
> Subject: Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly
> Elemental functions) for C
>
> O
committed as revision 205964 with updated comment.
kenny
2013-12-13 Kenneth Zadeck
* config/arc/arc.h (BITS_PER_UNIT): Removed.
* config/bfin/bfin.h (BITS_PER_UNIT): Removed.
* config/lm32/lm32.h (BITS_PER_UNIT): Removed.
* config/m32c/m32c.h (BITS_PER_UNIT): Removed.
* c
> Then I think we can put all bits together now:
>
> 1. Let Sandra apply her Bit-fields patch "reimplement
> -fstrict-volatile-bitfields v4, part 1/2" which was
> posted here: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
> and approved here: http://gcc.gnu.org/ml/gcc-patches/2013-10/msg
Unfortunately, the g++.dg/cilk-plus testsuite repeated many of the
errors that have already been fixed in its gcc.dg counterpart: not
properly setting ld_library_path (setting instead of appending, which
causes all 64-bit tests to FAIL on Solaris 10/x86) and using
ALWAYS_CFLAGS (leads to build dire
gcc/
* tree-predcom.c (find_looparound_phi): Return a gimple_phi rather
than just a gimple.
(insert_looparound_copy): Require a gimple_phi rather than just a
gimple.
(add_looparound_copies): Convert local "phi" to be a gimple_phi.
(initialize_root_var
gcc/
* coretypes.h (gimple_phi): New typedef.
(const_gimple_phi): New typedef.
* gimple.h (gimple_statement_base::as_a_gimple_phi): New.
(gimple_statement_base::dyn_cast_gimple_phi): New.
* gdbhooks.py (build_pretty_printer): Add gimple_phi and its
gcc/
* tree-ssa-loop-manip.c (add_exit_phi): Convert local "phi" to be a
gimple_phi.
(split_loop_exit_edge): Likewise for "phi" and "new_phi".
---
gcc/tree-ssa-loop-manip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-ssa-loop-manip.c b/g
gcc/
* tree-parloops.c (struct reduction_info): Strengthen field "new_phi"
from gimple to gimple_phi.
(create_phi_for_local_result): Convert local "new_phi" to gimple_phi.
(loop_has_vector_phi_nodes): Require a gimple_phi rather than a gimple.
(gather_scalar_
gcc/
* tree-ssa-phiprop.c (phiprop_insert_phi): Strengthen types of
parameter "phi" and local "new_phi" from gimple to gimple_phi.
---
gcc/tree-ssa-phiprop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-ssa-phiprop.c b/gcc/tree-ssa-phiprop.c
inde
gcc/
* tree-ssa-loop-niter.c (chain_of_csts_start): Return a gimple_phi
rather than a gimple.
(get_base_for): Likewise; convert local "phi" to be a gimple_phi.
(loop_niter_by_eval): Convert local "phi" to be a gimple_phi.
---
gcc/tree-ssa-loop-niter.c | 11 ++---
gcc/
* tree-ssa-propagate.h (typedef ssa_prop_visit_phi_fn): Strengthen
type of parameter from gimple to gimple_phi.
* tree-complex.c (complex_visit_phi): Update signature of callback
implementation accordingly.
* tree-ssa-ccp.c (ccp_visit_phi_node): Likewis
Hi,
On Wed, Dec 11, 2013 at 02:55:26PM +0100, Jan Hubicka wrote:
> > On 12/10/2013 04:48 AM, Jan Hubicka wrote:
> > >The case where I played with local comdats was the following.
> > >I made cgraph_body_availability to get context argument (i.e. instead of
> > >saying
> > >if something is availab
gcc/
* tree-ssa-loop-ivopts.c (determine_biv_step): Require a gimple_phi.
(find_bivs): Convert local "phi" into a gimple_phi.
(mark_bivs): Likewise.
---
gcc/tree-ssa-loop-ivopts.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/tree-ssa-loop-iv
gcc/
* coretypes.h (gimple_cond): New typedef.
(const_gimple_cond): Likewise.
* gimple.h (struct gimple_statement_cond): New subclass of
gimple_statement_with_ops, adding the invariant that
stmt->code == GIMPLE_COND.
(gimple_statement_base::as_a_gimp
gcc/
* coretypes.h (gimple_debug): New typedef.
(const_gimple_debug): New typedef.
* gimple.h (struct gimple_statement_debug): New subclass of
gimple_statement_with_ops, adding the invariant that
stmt->code == GIMPLE_DEBUG.
(gimple_statement_base::as
gcc/
* coretypes.h (gimple_label): New typedef.
(const_gimple_label): New typedef.
* gimple.h (struct gimple_statement_label): New subclass of
gimple_statement_with_ops, adding the invariant that
stmt->code == GIMPLE_LABEL.
(gimple_statement_base::as
gcc/
* gimple.h (gimple_statement_switch): New subclass of
gimple_statement_with_ops, adding the invariant that
stmt->code == GIMPLE_SWITCH.
(gimple_statement_base::as_a_gimple_switch): New.
(gimple_statement_base::dyn_cast_gimple_switch): New.
(is_a_
gcc/
* coretypes.h (gimple_assign): New typedef.
(const_gimple_assign): New typedef.
* gimple.h (struct gimple_statement_assign): New subclass of
gimple_statement_with_memory_ops, adding the invariant that
stmt->code == GIMPLE_ASSIGN.
(gimple_stateme
This updates all of the gimple_bind_* accessors in gimple.h from taking a
plain gimple to taking a gimple_bind (or const_gimple_bind), with the
checking happening at the point of cast.
Various other types are strengthened from gimple to gimple_bind, and from
plain vec to vec.
gcc/
* coret
As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
statements form a C++ inheritance hierarchy, but we're not yet making much
use of that in the code: everything refers to just "gimple" (or
"const_gimple"), and type-che
gcc/
* gimple.h (gimple_assign_single_p): Accept a const_gimple rather
than a gimple.
(gimple_store_p): Likewise.
(gimple_assign_load_p): Likewise.
(gimple_assign_cast_p): Likewise.
(gimple_clobber_p): Likewise.
---
gcc/gimple.h | 10 +-
1 fi
> On 12/13/2013 05:58 AM, Jan Hubicka wrote:
> >>+ if (callee->calls_comdat_local)
> >>+to->calls_comdat_local = true;
> >>+ else if (to->calls_comdat_local && symtab_comdat_local_p (callee))
> >>+{
> >>+ struct cgraph_edge *se = to->callees;
> >>+ for (; se; se = se->next_calle
On Thu, 2013-12-12 at 22:51 -0500, Jason Merrill wrote:
> I often use input_line in breakpoint conditions when debugging the
> compiler, and losing the macro complicates that. Any objection to
> adding it to gdbinit.in?
Fine by me.
On Dec 13, 2013, at 5:11 AM, Richard Biener wrote:
> On Fri, 13 Dec 2013, Uros Bizjak wrote:
>
>> Hello!
>>
>>> In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT
>>> is calculated.
>>> The value is heavily used on the wide-int branch to allocate buffers that
>>>
We can't change -fPIC underneath in x86 backend while middle-end is unchanged.
This patch restores opts->x_flag_pic from global flag_pic. OK to install?
Thanks.
H.J.
---
2013-12-12 H.J. Lu
PR target/59492
* config/i386/i386.c (ix86_function_specific_restore): Don't
On Thu, Dec 12, 2013 at 5:36 AM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 11:51:55AM -0500, Jason Merrill wrote:
>> It's only safe to free the targs if they weren't used to instantiate
>> any templates, so I lean toward option #1. Did you test this with
>> strict gc?
>
> Ok, after IRC discu
On 12/13/2013 05:58 AM, Jan Hubicka wrote:
+ if (callee->calls_comdat_local)
+to->calls_comdat_local = true;
+ else if (to->calls_comdat_local && symtab_comdat_local_p (callee))
+{
+ struct cgraph_edge *se = to->callees;
+ for (; se; se = se->next_callee)
+ if (se->inlin
On Fri, Dec 13, 2013 at 2:42 PM, Yuri Rumyantsev wrote:
> Attached is one-line fix which reduced a cost of integer
> multiplication for HI mode since imul instruction design was improved
> in SLM (in comparison with Atom).
>
> Is it OK for trunk?
>
> ChangeLog:
>
> 2013-12-13 Yuri Rumyantsev
Hi All,
Attached is one-line fix which reduced a cost of integer
multiplication for HI mode since imul instruction design was improved
in SLM (in comparison with Atom).
Is it OK for trunk?
ChangeLog:
2013-12-13 Yuri Rumyantsev
* config/i386/i386.c (slm_cost): Fix imul cost for HI.
x86-SL
Thanks for your help Vlad. Another bad news about this PR fix, is
that it has resurrected the thumb_movhi_clobber bug (PR 58785) but in
a different manner as the original failing testcase still pass. I
attached a testcase to be compiled with :
cc1 -mthumb -mcpu=cortex-m0 -O2 m.c
And Thumb boots
On Mon, Dec 2, 2013 at 6:46 PM, Sriraman Tallam wrote:
> On Thu, Nov 28, 2013 at 9:36 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> On Wed, 27 Nov 2013 19:49:39, Uros Bizjak wrote:
>>>
>>> On Mon, Nov 25, 2013 at 10:08 PM, Sriraman Tallam
>>> wrote:
>>>
I have attached a patch to fix this bug :
> On 2013.12.06 at 10:43 +0100, Richard Biener wrote:
> > On Fri, 6 Dec 2013, Jan Hubicka wrote:
> >
> > > > On Thu, 21 Nov 2013, Jan Hubicka wrote:
> > > >
> > > > > >
> > > > > > Why do you need an additional -fparallelism? Wouldn't
> > > > > > -fwpa=... be a better match, matching -flto=...?
On 2013.12.06 at 10:43 +0100, Richard Biener wrote:
> On Fri, 6 Dec 2013, Jan Hubicka wrote:
>
> > > On Thu, 21 Nov 2013, Jan Hubicka wrote:
> > >
> > > > >
> > > > > Why do you need an additional -fparallelism? Wouldn't
> > > > > -fwpa=... be a better match, matching -flto=...? As we already
On Fri, Dec 13, 2013 at 12:08 PM, Eric Botcazou wrote:
>> Instead I'd suggest to keep a 'last_field_array_p' flag that you can
>> check at the end of the loop.
>
> OK, I can do that.
>
>> + && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
>> + && !integer_zerop (TYPE_SIZE (TREE_TYPE (TREE_
On Fri, 13 Dec 2013, Uros Bizjak wrote:
> Hello!
>
> > In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT
> > is calculated.
> > The value is heavily used on the wide-int branch to allocate buffers that
> > are used to hold large
> > integer values. The change in the wa
> Instead I'd suggest to keep a 'last_field_array_p' flag that you can
> check at the end of the loop.
OK, I can do that.
> + && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> + && !integer_zerop (TYPE_SIZE (TREE_TYPE (TREE_TYPE (field)
> +return;
> +
>
> Why does this exclude z
Hi,
I've added option -foffload-target to specify target and options for
target compiler for offloading.
Please, have a look.
--
Best regards,
Andrey Turetskiy
foffload_option.patch
Description: Binary data
> On 12/12/2013 03:08 PM, Jan Hubicka wrote:
> >So only reason why this is optimize_size only is the fact that we can't rely
> >on inliner
> >to fix up the wrappers?
>
> I was just being conservative. In fact, the inliner seems to handle
> small [cd]tors well, inlining them into the wrappers and
Hello!
> In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT
> is calculated.
> The value is heavily used on the wide-int branch to allocate buffers that are
> used to hold large
> integer values. The change in the way it is computed was motivated by the
> i386 port, but
On Wed, Dec 11, 2013 at 8:19 PM, Eric Botcazou wrote:
>> Yes we do, even for struct { struct { int a; char a[1] } }; (note the not
>> really "trailing" as there is padding after the trailing array). We do
>> take size limitations from a DECL (if we see one) into account to limit the
>> effect of
On Thu, Dec 12, 2013 at 6:55 AM, bin.cheng wrote:
>
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Wednesday, December 11, 2013 6:04 PM
>> To: Jakub Jelinek
>> Cc: Bin.Cheng; Jeff Law; Bin Cheng; gcc-patches List
>> Subject: Re: [PATCH PR41488]
On Wed, 11 Dec 2013, Kenneth Zadeck wrote:
>
>
> This patch is for the trunk, but it solves a problem that comes up for
> wide-int. For wide-int we need to have the BITS_PER_UNIT available earlier.
> So this patch sets the default value (8) in genmodes.c so that it is available
> by anyone who
[This time with the patch attached]
Hi Guys,
I have applied the patch below to add support for a wakeup function
attribute to the MSP430 backend. The wakeup attribute applies to
interrupt functions, and it makes them wake the processor from low
power sleep states when the i
> with Eric's patch this test case does no longer compile, while it did
> compile with my patch:
>
> $ cat test.c
> struct s{ char x[8]; };
> int main()
> {
> volatile register struct s x __asm__("eax");
> x.x[0] = 1;
> return x.x[0];
> }
>
> $ gcc -O3 -S test.c
> test.c: In function 'main
Hi!
On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> 4) the reference testcase showed a problem with fold_stmt calls
> we do very early, during gimplification, because for TREE_READONLY
> vars with DECL_INITIAL fold_stmt can replace the uses of the var with
> its initializer, but as the
Hi!
OK to apply the following cleanup patches to trunk, assuming that testing
(still running) is fine?
commit 68c9deec084dff1e5d8caf6a17ec3eec1f8f9f33
Author: Thomas Schwinge
Date: Wed Oct 23 19:40:10 2013 +0200
Fix description of OpenMP parallel directive in the C and C++ front ends.
Hi Guys,
I have applied the patch below to add support for a wakeup function
attribute to the MSP430 backend. The wakeup attribute applies to
interrupt functions, and it makes them wake the processor from low
power sleep states when the interrupt handler exits.
Cheers
Nick
gcc/ChangeL
On Wed, Dec 11, 2013 at 6:47 PM, Oleg Endo wrote:
> On Thu, 2013-11-21 at 00:04 +0100, Steven Bosscher wrote:
>> Declaring the edge_iterator inside the for() is not a good argument
>> against FOR_EACH_EDGE. Of course, brownie points are up for grabs for
>> the brave soul daring enough to make edge
Hi,
with Eric's patch this test case does no longer compile, while it did compile
with my patch:
$ cat test.c
struct s{ char x[8]; };
int main()
{
volatile register struct s x __asm__("eax");
x.x[0] = 1;
return x.x[0];
}
$ gcc -O3 -S test.c
test.c: In function 'main':
test.c:4:30: error
On Wed, Dec 11, 2013 at 9:25 PM, Jeff Law wrote:
> On 12/11/13 02:51, Richard Biener wrote:
>>
>>
>> That looks wrong - you want to look at HONOR_NANS on the mode
>> of one of the comparison operands, not of the actual value you want
>> to negate (it's integer and thus never has NaNs).
>>
>> The r
Jakub Jelinek wrote:
>On Fri, Dec 13, 2013 at 07:30:12AM +0100, Richard Biener wrote:
>> Jakub Jelinek wrote:
>> >lhs of a call for calls or somewhere in output arguments of inline
>asm.
>>
>> Can you please simply use walk_stmt_load_store_ops to get at the stmt
>outputs?
>
>No, unfortunately.
> OK, now it works.
Thanks for confirming, I've installed the patch.
> I wonder if you could add some really good comments in the system.ads
> what's the problem and how to fix it if the No_Implicit_Dynamic_Code
> makes problems like these?
I think that we need to catch the problem earlier, that
> Does this catch C99 VLAs? I vaguely recall we have a different internal
> representation of those?!? And don't those have the same problem?
No, VLAs have explicit variable size so they are not problematic here.
--
Eric Botcazou
Hi Eric,
>
> OK, I think that this compiler is misconfigured, could you try this
>
> Index: gcc-interface/Makefile.in
> ===
> --- gcc-interface/Makefile.in (revision 205918)
> +++ gcc-interface/Makefile.in (working copy)
> @@ -1903,7
77 matches
Mail list logo
