On 03/04/2016 08:13 AM, Bernd Schmidt wrote:
On 03/04/2016 03:27 PM, Patrick Palka wrote:
I still suggest to try making write_test_expr() avoid emitting
redundant parentheses for chains of || or &&, which would fix the
original issue all the same. Previously you claimed that such a
change would
On Fri, Mar 4, 2016 at 12:49 PM, Bernd Schmidt wrote:
> On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
>>
>> On 03/04/2016 06:14 PM, Patrick Palka wrote:
>>
>>> I just quickly tested building the generated insn-attrtab.c with and
>>> without the patch using my host gcc 5.3 compiler and the .s output
On Fri, Mar 04, 2016 at 07:01:10PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 06:56 PM, Jakub Jelinek wrote:
> >I think we don't need to guarantee identical assembly, the reason I've
> >suggested that was if it passed, it would be much easier to verify.
> >Without that, I think it should be bootst
On 03/04/2016 06:56 PM, Jakub Jelinek wrote:
I think we don't need to guarantee identical assembly, the reason I've
suggested that was if it passed, it would be much easier to verify.
Without that, I think it should be bootstrapped at least on one other
target. Note the cases you remove the pare
On Fri, Mar 04, 2016 at 06:49:58PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
> >On 03/04/2016 06:14 PM, Patrick Palka wrote:
> >
> >>I just quickly tested building the generated insn-attrtab.c with and
> >>without the patch using my host gcc 5.3 compiler and the .s
On 03/04/2016 06:27 PM, Bernd Schmidt wrote:
On 03/04/2016 06:14 PM, Patrick Palka wrote:
I just quickly tested building the generated insn-attrtab.c with and
without the patch using my host gcc 5.3 compiler and the .s output is
not the same.
Hmm, looking at the 003t.original dump it looks li
On 03/04/2016 05:03 PM, Jesper Broge Jørgensen wrote:
I can look into that if you deem it worth it, or would you rather just
go with Patriks suppressed parenthesis?
For the moment (in stage4) we'll at most go with Patrick's patch.
Whether we do anything beyond that depends on whether we can d
On 03/04/2016 06:14 PM, Patrick Palka wrote:
I just quickly tested building the generated insn-attrtab.c with and
without the patch using my host gcc 5.3 compiler and the .s output is
not the same.
Hmm, looking at the 003t.original dump it looks like there are
differences in SAVE_EXPRs. Indee
On Fri, Mar 4, 2016 at 11:42 AM, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 11:34:06AM -0500, Patrick Palka wrote:
>> * genattrtab.c (write_test_expr): New parameter EMIT_PARENS
>> which defaults to true. Emit an outer pair of parentheses only if
>> EMIT_PARENS. When contin
On Fri, Mar 04, 2016 at 11:34:06AM -0500, Patrick Palka wrote:
> * genattrtab.c (write_test_expr): New parameter EMIT_PARENS
> which defaults to true. Emit an outer pair of parentheses only if
> EMIT_PARENS. When continuing a chain of && or ||, don't emit
> parentheses for
On Fri, 4 Mar 2016, Jakub Jelinek wrote:
> On Fri, Mar 04, 2016 at 04:13:41PM +0100, Bernd Schmidt wrote:
> > On 03/04/2016 03:27 PM, Patrick Palka wrote:
> > >>>I still suggest to try making write_test_expr() avoid emitting
> > >>>redundant parentheses for chains of || or &&, which would fix the
On 04/03/16 16:13, Bernd Schmidt wrote:
On 03/04/2016 03:27 PM, Patrick Palka wrote:
I still suggest to try making write_test_expr() avoid emitting
redundant parentheses for chains of || or &&, which would fix the
original issue all the same. Previously you claimed that such a
change would not
On Fri, Mar 04, 2016 at 04:13:41PM +0100, Bernd Schmidt wrote:
> On 03/04/2016 03:27 PM, Patrick Palka wrote:
> >>>I still suggest to try making write_test_expr() avoid emitting
> >>>redundant parentheses for chains of || or &&, which would fix the
> >>>original issue all the same. Previously you
On 03/04/2016 03:27 PM, Patrick Palka wrote:
I still suggest to try making write_test_expr() avoid emitting
redundant parentheses for chains of || or &&, which would fix the
original issue all the same. Previously you claimed that such a
change would not be simpler than your current patch, but I
On Fri, 4 Mar 2016, David Malcolm wrote:
On Thu, 2016-03-03 at 17:36 -0500, Patrick Palka wrote:
On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
wrote:
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
T
On Thu, 2016-03-03 at 17:36 -0500, Patrick Palka wrote:
> On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
> wrote:
> >
> > On 18/02/16 13:22, Bernd Schmidt wrote:
> > >
> > > On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
> > > >
> > > > Here is the reformatted patch:
> > >
> > >
On Thu, Mar 3, 2016 at 4:29 PM, Jesper Broge Jørgensen
wrote:
>
> On 18/02/16 13:22, Bernd Schmidt wrote:
>>
>> On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
>>>
>>> Here is the reformatted patch:
>>
>>
>> This will probably have to wait until stage1.
>>
>>> + const int code = GET_COD
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting
On 18/02/16 13:22, Bernd Schmidt wrote:
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting
On 01/19/2016 12:47 PM, Jesper Broge Jørgensen wrote:
Here is the reformatted patch:
This will probably have to wait until stage1.
+ const int code = GET_CODE (op2);
+ if (code != IOR)
+{
+ if (code == EQ_ATTR)
All the formatting still looks completely mangled. This was p
On 19/01/16 10:44, Richard Biener wrote:
On Mon, Jan 18, 2016 at 7:48 PM, Jeff Law wrote:
On 01/18/2016 07:09 AM, Jesper Broge Jørgensen wrote:
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
I'd put it in my gcc-7 queue. But if Richard, Bernd, Richi or someone else
wa
On 01/02/16 20:19, Patrick Palka wrote:
On Tue, Jan 12, 2016 at 7:53 PM, Jesper Broge Jørgensen
wrote:
Hello
genattrab.c can generate if statements that have very deep bracket nesting
causing clang to produce errors (when target=arm-none-eabi) as explained at
https://gcc.gnu.org/ml/gcc/2014-0
On Tue, Jan 12, 2016 at 7:53 PM, Jesper Broge Jørgensen
wrote:
> Hello
>
> genattrab.c can generate if statements that have very deep bracket nesting
> causing clang to produce errors (when target=arm-none-eabi) as explained at
> https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
> At the above link
On 19/01/16 13:18, Bernd Schmidt wrote:
On 01/18/2016 11:44 PM, Jesper Broge Jørgensen wrote:
I found a formatting tool called uncrustify that comes with a gnu style
config
https://github.com/bengardner/uncrustify/blob/master/etc/gnu-indent.cfg
that needed a few tweaks to format code that look
On 01/18/2016 11:44 PM, Jesper Broge Jørgensen wrote:
I found a formatting tool called uncrustify that comes with a gnu style
config
https://github.com/bengardner/uncrustify/blob/master/etc/gnu-indent.cfg
that needed a few tweaks to format code that looked what is already in
gcc/genattrtab.c
The
On 19/01/16 10:44, Richard Biener wrote:
On Mon, Jan 18, 2016 at 7:48 PM, Jeff Law wrote:
On 01/18/2016 07:09 AM, Jesper Broge Jørgensen wrote:
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
I'd put it in my gcc-7 queue. But if Richard, Bernd, Richi or someone else
wa
On Mon, Jan 18, 2016 at 7:48 PM, Jeff Law wrote:
> On 01/18/2016 07:09 AM, Jesper Broge Jørgensen wrote:
>>
>> Ping patch:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
>
> I'd put it in my gcc-7 queue. But if Richard, Bernd, Richi or someone else
> wants to work though the chang
On 18/01/16 18:39, Manuel López-Ibáñez wrote:
On 18/01/16 14:39, Jesper Broge Jørgensen wrote:
No i have not gone through copyright assignment.
This is my first time trying to contribute to a GNU project so i have
tried
following the "Contributing to GCC"@
https://gcc.gnu.org/contribute.html
On 01/18/2016 07:09 AM, Jesper Broge Jørgensen wrote:
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
I'd put it in my gcc-7 queue. But if Richard, Bernd, Richi or someone
else wants to work though the changes as a bugfix for bootstrapping on
platforms with crippled compi
On 18/01/16 14:39, Jesper Broge Jørgensen wrote:
No i have not gone through copyright assignment.
This is my first time trying to contribute to a GNU project so i have tried
following the "Contributing to GCC"@
https://gcc.gnu.org/contribute.html
There i followed the advice to run the patch throu
On 18/01/16 15:15, Bernd Schmidt wrote:
On 01/13/2016 01:53 AM, Jesper Broge Jørgensen wrote:
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
A
On Mon, Jan 18, 2016 at 03:15:08PM +0100, Bernd Schmidt wrote:
> Secondly, we're currently in a development phase where we only accept bug
> fixes for gcc-6. You should resubmit/ping the patch once stage1 opens again.
I think this is a bug fix, it is a workaround for a broken compiler that
some pe
On 01/13/2016 01:53 AM, Jesper Broge Jørgensen wrote:
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
At the above link it was suggested that gen
Ping patch:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00784.html
thanks
Hello
genattrab.c can generate if statements that have very deep bracket
nesting causing clang to produce errors (when target=arm-none-eabi) as
explained at https://gcc.gnu.org/ml/gcc/2014-05/msg00032.html
At the above link it was suggested that genattrab.c generated a switch
statement instead
35 matches
Mail list logo
