05/22/16 22:02, Uros Bizjak wrote:
> On Sun, May 22, 2016 at 9:00 AM, Bernd Edlinger
> wrote:
>> Hi!
>>
>> as described in the PR there are several non-intuitive rules that
>> one has to follow to avoid ICEs with x87 asm operands.
>>
>> This patch adds an
Ping...
I think we all agreed on the general direction of this patch.
The patch is basically unchanged from previous version,
except one line in doc/extend.texi has been updated.
So I would like to ask if it is OK for trunk.
Thanks
Bernd.gcc/
2016-05-05 Bernd Edlinger
PR c/24414
Ping...
see https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02010.html
Thanks
Bernd.
On 05/25/16 14:58, Bernd Edlinger wrote:
> Hi!
>
> This restricts the X constraint in asm statements, which
> can be easily folded by combine in something completely
> invalid.
>
> It
On 06/06/16 20:08, Jakub Jelinek wrote:
> On Mon, Jun 06, 2016 at 12:04:04PM -0600, Jeff Law wrote:
>> On 06/06/2016 12:01 PM, Jakub Jelinek wrote:
>>> On Mon, Jun 06, 2016 at 11:54:04AM -0600, Jeff Law wrote:
> As for recog.c, I can not approve this as I am not a maintainer of it.
> I only
On 06/09/16 18:45, Jakub Jelinek wrote:
> On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote:
>> Yes, I'm all in favor in disabling X constraint for inline asm.
>> Especially if people actually try to print it as well, rather than make it
>> unused. That is a sure path to ICEs.
>
> Thou
Hi,
this trivial patch removes two unused extern declarations in arm.h.
Boot-strapped and reg-tested on arm-linux-gnueabihf.
OK for trunk?
Thanks
Bernd.
2016-06-10 Bernd Edlinger
* config/arm/arm.h (pool_vector_label,
return_used_this_function): Removed.
Index: gcc/config/arm/arm.h
On 06/10/16 20:42, Jakub Jelinek wrote:
>
> The second testcase FAILs on both x86_64 and i686, because it contains
> no dg-options, therefore is compiled with -ansi -pedantic and that doesn't
> allow GNU inline asm syntax. While looking at the testcase, I believe you
> meant to make it executable,
Hi,
this fixes an ICE that happens when an asm statement tries to print
the flags output operand.
Boot-strapped and reg-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.gcc:
2016-06-11 Bernd Edlinger
* config/i386/i386.c (print_reg): Emit an error message on attempt to
language setting.
Boot-strapped and reg-tested on trunk with LANG=de_DE.UTF-8.
OK to commit?
Thanks
Bernd.2016-06-13 Bernd Edlinger
* input.c (test_builtins): Fix an assertion.
Index: gcc/input.c
===
--- gcc/input.c (Revision
On 06/13/16 17:27, David Malcolm wrote:
> On Mon, 2016-06-13 at 14:41 +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> as noted in PR bootstrap/71481, comment#4 currently
>> the trunk fails to bootstrap if the current language is
>> not english. A workaround is possible
compute_frame_layout target hook just
for ARM in the moment, to show the principle.
Other targets may also implement that hook, if it seems appropriate.
Boot-strapped and reg-tested on arm-linux-gnueabihf.
OK for trunk?
Thanks
Bernd.
2016-06-16 Bernd Edlinger
* target.def (compute_frame_layout
Hi,
ping...
As this discussion did not make any progress, I just attached
the latest version of my patch with the the changes that
Vladimir proposed.
Boot-strapped and reg-tested again on x86_64-linux-gnu.
Is it OK for the trunk?
Thanks
Bernd.
On 06/10/16 16:13, Bernd Edlinger wrote:
>
On 06/21/16 00:06, Jeff Law wrote:
> On 06/09/2016 10:45 AM, Jakub Jelinek wrote:
>> On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote:
>>> Yes, I'm all in favor in disabling X constraint for inline asm.
>>> Especially if people actually try to print it as well, rather than
>>> make it
Ping...
for this patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00871.html
I'd say it's a no-brainer...
> Hi,
>
> this fixes an ICE that happens when an asm statement tries to print
> the flags output operand.
>
> Boot-strapped and reg-tested on x86_64-linux-gnu.
> OK for trunk?
>
>
>
Oh, yes.
Uros... ?
Thanks
Bernd.
Am 21.06.2016 um 17:04 schrieb Jeff Law:
> On 06/21/2016 02:09 AM, Bernd Edlinger wrote:
>> Ping...
>>
>> for this patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00871.html
>>
>> I'd say it's a no-brainer...
>
On 06/21/16 23:29, Jeff Law wrote:
> On 06/16/2016 08:47 AM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> By the design of the target hook INITIAL_ELIMINATION_OFFSET
>> it is necessary to call this function several times with
>> different register combinations.
>
On 06/21/16 23:29, Jeff Law wrote:
>
> How does this macro interact with INITIAL_FRAME_POINTER_OFFSET?
That I forgot to mention: INITIAL_FRAME_POINTER_OFFSET is just
a single call, so whenever it is called from lra/reload the frame layout
is really expected to change, and so it does not make a di
On 06/22/16 20:49, Jeff Law wrote:
> On 06/21/2016 11:12 PM, Bernd Edlinger wrote:
>
>>
>> What I wanted to say here, is that lra goes thru several iterations,
>> changes something in the register allocation that has an impact on the
>> frame layout,
On 06/22/16 21:51, Jeff Law wrote:
> On 06/19/2016 07:25 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> ping...
>>
>> As this discussion did not make any progress, I just attached
>> the latest version of my patch with the the changes that
>> Vladimir proposed
Hi Segher,
the patch looks ok for me.
Just for my understanding:
A memory clobber would also make rtx_moveable_p return false,
thru the following case:
case MEM:
if (type == OP_IN && MEM_READONLY_P (x))
return rtx_moveable_p (&XEXP (x, 0), OP_IN);
return false;
...
c
On 10/18/17 13:30, Segher Boessenkool wrote:
> On Wed, Oct 18, 2017 at 11:10:48AM +0000, Bernd Edlinger wrote:
>> A memory clobber would also make rtx_moveable_p return false,
>> thru the following case:
>>
>> case MEM:
>>if (type == OP_IN &&am
On 10/18/17 15:46, Segher Boessenkool wrote:
> On Wed, Oct 18, 2017 at 06:30:23AM -0500, Segher Boessenkool wrote:
>> On Wed, Oct 18, 2017 at 11:10:48AM +0000, Bernd Edlinger wrote:
>>> A memory clobber would also make rtx_moveable_p return false,
>>> thru the following
Ping...
for the latest version of my patch which can be found here:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00559.html
Thanks
Bernd.
On 10/10/17 00:30, Bernd Edlinger wrote:
> On 10/09/17 20:34, Martin Sebor wrote:
>> On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
>>>
Ping...
On 06/14/17 14:33, Bernd Edlinger wrote:
> Ping...
>
> On 06/01/17 18:00, Bernd Edlinger wrote:
>> Ping...
>>
>> On 05/12/17 18:49, Bernd Edlinger wrote:
>>> Ping...
>>>
>>> On 04/29/17 19:21, Bernd Edlinger wrote:
>>
Ping...
The latest version of this patch was here:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01567.html
Thanks
Bernd.
On 06/14/17 14:34, Bernd Edlinger wrote:
> Ping...
>
> On 06/01/17 18:01, Bernd Edlinger wrote:
>> Ping...
>>
>> On 05/12/17 18:49, Ber
to wait for the next stable debian version.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-07-18 Bernd Edlinger
* lib/gcc-dg.exp: Increase expect's match buffer size.
Index: gcc/testsuite/lib/gcc-d
Hi,
I would like to kindly remind you of the following patches,
which are already waiting for over 6 months:
[PATCH, ARM] correctly encode the CC reg data flow
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01351.html
[PATCH, ARM] Further improve stack usage in sha512 (PR 77308)
https://gcc.gnu.o
Ping...
it would be nice if this could be reviewed before next stage 3.
Thanks
Bernd.
On 08/01/17 16:32, Bernd Edlinger wrote:
> Hi,
>
> I would like to kindly remind you of the following patches,
> which are already waiting for over 6 months:
>
> [PATCH, ARM] correctly enco
-03 Bernd Edlinger
* common.opt (Wcast-align=strict): New warning option.
* doc/invoke.texi: Document -Wcast-align=strict.
c:
2017-09-03 Bernd Edlinger
* c-typeck.c (build_c_cast): Implement -Wcast-align=strict.
cp:
2017-09-03 Bernd Edlinger
Hi Kyrill,
Thanks for your review!
On 09/04/17 15:55, Kyrill Tkachov wrote:
> Hi Bernd,
>
> On 18/01/17 15:36, Bernd Edlinger wrote:
>> On 01/13/17 19:28, Bernd Edlinger wrote:
>>> On 01/13/17 17:10, Bernd Edlinger wrote:
>>>> On 01/13/17 14:50, Richard Ea
Hi Christophe,
On 09/05/17 10:45, Christophe Lyon wrote:
> Hi Bernd,
>
>
> On 4 September 2017 at 16:52, Kyrill Tkachov
> wrote:
>>
>> On 29/04/17 18:45, Bernd Edlinger wrote:
>>>
>>> Ping...
>>>
>>> I attached a rebased ver
On 09/05/17 17:02, Wilco Dijkstra wrote:
> Bernd Edlinger wrote:
>
>> Combine creates an invalid insn out of these two insns:
>
> Yes it looks like a latent bug. We need to use arm_general_register_operand
> as arm_adddi3/subdi3 only allow integer registers. You don'
On 09/05/17 23:27, Wilco Dijkstra wrote:
> Bernd Edlinger wrote:
>> No, the split condition does not begin with "&& TARGET_32BIT...".
>> Therefore the split is enabled in TARGET_NEON after reload_completed.
>> And it is invoked from adddi3_neon for al
On 09/04/17 21:54, Bernd Edlinger wrote:
> Hi Kyrill,
>
> Thanks for your review!
>
>
> On 09/04/17 15:55, Kyrill Tkachov wrote:
>> Hi Bernd,
>>
>> On 18/01/17 15:36, Bernd Edlinger wrote:
>>> On 01/13/17 19:28, Bernd Edlinger wrote:
>>>>
On 09/06/17 14:51, Richard Earnshaw (lists) wrote:
> On 06/09/17 13:44, Bernd Edlinger wrote:
>> On 09/04/17 21:54, Bernd Edlinger wrote:
>>> Hi Kyrill,
>>>
>>> Thanks for your review!
>>>
>>>
>>> On 09/04/17 15:55, Kyrill Tkachov wr
On 09/06/17 14:51, Richard Earnshaw (lists) wrote:
> On 06/09/17 13:44, Bernd Edlinger wrote:
>> On 09/04/17 21:54, Bernd Edlinger wrote:
>>> Hi Kyrill,
>>>
>>> Thanks for your review!
>>>
>>>
>>> On 09/04/17 15:55, Kyrill Tkachov wr
Ping...
On 09/04/17 10:07, Bernd Edlinger wrote:
> Hi,
>
> as you know we have a -Wcast-align warning which works only for
> STRICT_ALIGNMENT targets. But occasionally it would be nice to be
> able to switch this warning on even for other targets.
>
> Therefore I would
On 05/05/17 16:59, Richard Earnshaw (lists) wrote:
> On 05/09/16 17:43, Bernd Edlinger wrote:
>> Hi Richard,
>>
>> what do you think of this patch, is it OK (with the suggested wording)?
>>
>
> Bernd,
>
> Apologies, this seems to have fallen through a crack.
lowing and it
seems to work for x86_64-pc-linux-gnu and arm-linux-gnueabihf.
Is it OK for trunk?
Thanks
Bernd.2017-05-09 Bernd Edlinger
* raise-gcc.c (exception_class_eq): Make ec parameter const.
--- gcc/ada/raise-gcc.c.jj 2017-04-27 12:00:42.0 +0200
+++ gcc/ada/raise-gcc.c 2017-0
> that to "char*".
>>
>> Not sure what is the smartest solution, I tried the following and it
>> seems to work for x86_64-pc-linux-gnu and arm-linux-gnueabihf.
>>
>> Is it OK for trunk?
>
> Patch looks OK to me FWIW. Tristan?
>
so, shoul
Ping...
On 04/28/17 19:41, Bernd Edlinger wrote:
> Ping...
>
> I attached a rebased patch file, with the doc changes and
> merge conflicts with trunk of today fixed, but otherwise
> identical.
>
>
> Thanks
> Bernd.
>
> On 04/21/17 22:26, Bernd Edlinger wrote:
&
Ping...
On 04/29/17 09:06, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:
>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>>>
>>>
>>> Yes I agree, that is probably not worth it. So I could try to remove
>>> the special handling of PIC
Ping...
On 04/29/17 19:21, Bernd Edlinger wrote:
> Ping...
>
> On 04/20/17 20:11, Bernd Edlinger wrote:
>> Ping...
>>
>> for this patch:
>> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01351.html
>>
>> On 01/18/17 16:36, Bernd Edlinger wrote:
>>
Ping...
On 04/29/17 19:45, Bernd Edlinger wrote:
> Ping...
>
> I attached a rebased version since there was a merge conflict in
> the xordi3 pattern, otherwise the patch is still identical.
> It splits adddi3, subdi3, anddi3, iordi3, xordi3 and one_cmpldi2
> early when the tar
Ping...
On 04/29/17 19:52, Bernd Edlinger wrote:
> Ping...
>
> I attached the latest version of my patch.
>
>
> Thanks
> Bernd.
>
> On 12/18/16 14:14, Bernd Edlinger wrote:
>> Hi,
>>
>> this splits the *arm_negdi2, *arm_cmpdi_insn and *arm_cmpdi_unsi
Ping for the C changes.
Thanks
Bernd.
On 05/03/17 15:14, Jason Merrill wrote:
> On Tue, May 2, 2017 at 9:26 AM, Bernd Edlinger
> wrote:
>> On 05/01/17 17:54, Jason Merrill wrote:
>>> On Fri, Apr 28, 2017 at 1:05 PM, Bernd Edlinger
>>> wrote:
>>>> On 04
frame layout can no longer change spontaneously.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-05-14 Bernd Edlinger
* config/i386/i386.c (ix86_can_use_return_insn_p): Use the ix86_frame
data structure directly
e computed from a different function.
Bernd.
On 05/14/17 12:25, Uros Bizjak wrote:
> On Sun, May 14, 2017 at 11:16 AM, Daniel Santos
> wrote:
>> On 05/14/2017 02:42 AM, Bernd Edlinger wrote:
>>>
>>> Hi,
>>>
>>>
>>> this patch uses the new TARG
On 05/15/17 03:39, Daniel Santos wrote:
> On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
>> Hi Daniel,
>>
>> there is one thing I don't understand in your patch:
>> That is, it introduces a static value:
>>
>> /* Registers who's save & res
On 05/16/2017 07:00, Daniel Santos wrote:
>
> Ian, would you mind looking at this please? A combination of my
> -mcall-ms2sysv-xlogues patch with Bernd's patch is causing problems when
> ix86_expand_split_stack_prologue() calls ix86_expand_call().
Here is what I am testing currently.
I fixed the
not
happen every time. Currently I think that is unrelated to this patch.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu with -m64/-m32.
Is it OK for trunk?
Thanks
Bernd.
2017-05-16 Bernd Edlinger
* config/i386/i386.c (x86_64_ms_sysv_extra_clobbered_registers):
On 05/16/17 21:52, Bernd Edlinger wrote:
> The calls_eh_return and ix86_static_chain_on_stack may become
> known at a later time, but after reload it should not change any more.
> To be sure, I added an assertion at ix86_static_chain, which the
> regression test did not trigger, neith
On 05/17/17 04:01, Daniel Santos wrote:
> On 05/16/2017 02:52 PM, Bernd Edlinger wrote:
>> I think I solved the problem with -fsplit-stack, I am not sure
>> if ix86_static_chain_on_stack might change after reload due to
>> final.c possibly calling targetm.calls.static_chain,
On 05/15/17 03:39, Daniel Santos wrote:
> On 05/14/2017 11:31 AM, Bernd Edlinger wrote:
>> Hi Daniel,
>>
>> there is one thing I don't understand in your patch:
>> That is, it introduces a static value:
>>
>> /* Registers who's save & res
aved at all, because it can easily be reconstructed
from m->call_ms2sysv_extra_regs.
See the attached new version. Daniel does it work for you?
Bootstrapped and reg-tested on x86_64-pc-linux-gnu with
--target_board=unix\{,-m32\}.
Is it OK for trunk?
Thanks
Bernd.
2017-05-16
-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc/c-family:
2017-05-18 Bernd Edlinger
* c-format.c (local_tree_type_node): Add GTY attribute.
gcc/c:
2017-05-18 Bernd Edlinger
* config-lang.in (gtfiles): Add c-family/c-format.c.
--- gcc/c-family/c-format.c.jj 2017-05-09 04:47
after successful reg-testing?
Thanks
Bernd.
On 05/18/17 17:33, Richard Biener wrote:
> On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger
> wrote:
>> Hi,
>>
>>
>> this attempts to fix occasional segmentation faults that are present in
>> the current s
Please disregard the unrelated change on cp/typeck.c, thanks.
On 05/18/17 17:33, Richard Biener wrote:
> On May 18, 2017 5:15:43 PM GMT+02:00, Bernd Edlinger
> wrote:
>> Hi,
>>
>>
>> this attempts to fix occasional segmentation faults that are present in
>>
On 05/19/17 09:51, Richard Biener wrote:
> On Thu, 18 May 2017, Bernd Edlinger wrote:
>
>> Hi,
>>
>> unfortunately the first patch was still insufficient. I identified many
>> more relatively new places where static tree objects are invisible to
>> GC.
On 05/19/17 16:10, Nathan Sidwell wrote:
> On 05/19/2017 10:05 AM, Bernd Edlinger wrote:
>
>> hwi cannot be the root cause of the problem,
>> because it can only be long_integer_type_node
>> or long_long_integer_type_node, otherwise
>> an error would be triggered
On 05/19/17 19:05, Dominique d'Humières wrote:
> Hi Bernd,
>
> Your patches are causing troubles when I try to do "incremental updates »:
>
> After revision r248290 it fails with
>
> ../../work/gcc/cp/init.c:4916:10: fatal error: gt-cp-init.h: No such file or
> directory
> #include "gt-cp-ini
On 05/19/17 05:17, Daniel Santos wrote:
> On 05/18/2017 08:37 AM, Bernd Edlinger wrote:
>> On 05/17/17 04:01, Daniel Santos wrote:
>>>> - if (ignore_outlined && cfun->machine->call_ms2sysv
>>>> - && in_hard_reg_set_p (stub_managed_r
with unix\{,-m32\}.
Is it OK for trunk?
Thanks
Bernd.
2017-05-23 Bernd Edlinger
* config/i386/i386.c (x86_64_ms_sysv_extra_clobbered_registers): Make
static.
(xlogue_layout::get_stack_space_used, xlogue_layout::s_instances,
xlogue_layout::get_instance, logue_l
Ping...
On 05/12/17 18:47, Bernd Edlinger wrote:
> Ping...
>
> On 04/28/17 19:41, Bernd Edlinger wrote:
>> Ping...
>>
>> I attached a rebased patch file, with the doc changes and
>> merge conflicts with trunk of today fixed, but otherwise
>> identical.
>
Ping...
On 05/12/17 18:48, Bernd Edlinger wrote:
> Ping...
>
> On 04/29/17 09:06, Bernd Edlinger wrote:
>> On 04/28/17 20:46, Jeff Law wrote:
>>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>>>>
>>>>
>>>> Yes I agree, that is pr
Ping...
On 05/12/17 18:49, Bernd Edlinger wrote:
> Ping...
>
> On 04/29/17 19:21, Bernd Edlinger wrote:
>> Ping...
>>
>> On 04/20/17 20:11, Bernd Edlinger wrote:
>>> Ping...
>>>
>>> for this patch:
>>> https://gcc.gnu.org/ml/gcc
Ping...
On 05/12/17 18:49, Bernd Edlinger wrote:
> Ping...
>
> On 04/29/17 19:45, Bernd Edlinger wrote:
>> Ping...
>>
>> I attached a rebased version since there was a merge conflict in
>> the xordi3 pattern, otherwise the patch is still identical.
>> I
Ping...
On 05/12/17 18:50, Bernd Edlinger wrote:
> Ping...
>
> On 04/29/17 19:52, Bernd Edlinger wrote:
>> Ping...
>>
>> I attached the latest version of my patch.
>>
>>
>> Thanks
>> Bernd.
>>
>> On 12/18/16 14:14, Be
Ping...
On 05/12/17 18:55, Bernd Edlinger wrote:
> Ping for the C changes.
>
> Thanks
> Bernd.
>
> On 05/03/17 15:14, Jason Merrill wrote:
>> On Tue, May 2, 2017 at 9:26 AM, Bernd Edlinger
>> wrote:
>>> On 05/01/17 17:54, Jason Merrill wrote:
>
Ping...
the latest version of this patch was posted here:
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01758.html
Thanks
Bernd.
On 05/23/17 16:31, Bernd Edlinger wrote:
> Hi,
>
> this is the latest version of my patch.
>
> As already said, it attempts to compute
> the fram
On 06/01/17 19:52, Nathan Sidwell wrote:
> On 06/01/2017 11:59 AM, Bernd Edlinger wrote:
>> Ping...
>
> What are you asking to be reviewed by who?
>
> nathan
>
Aehm, sorry.
This is a gcc option that converts relative
path names to absolute ones, so that gcov can
On 06/02/17 13:35, Nathan Sidwell wrote:
> On 06/01/2017 03:24 PM, Bernd Edlinger wrote:
>
>> This is a gcc option that converts relative
>> path names to absolute ones, so that gcov can
>> properly merge the line numbers in projects
>> where different relative path
ile (most likely). Isn't this already
> available somewhere?
>
>
No, at least grep does not see any other place, except in gcov-tool.c :(
So how about this new patch?
Is it OK for trunk?
Bernd.
gcc:
2017-04-21 Bernd Edlinger
* doc/invoke.texi: Docume
On 12/20/16 16:09, Wilco Dijkstra wrote:
> Bernd Edlinger wrote:
>> this splits the *arm_negdi2, *arm_cmpdi_insn and *arm_cmpdi_unsigned
>> also at split1 except for TARGET_NEON and TARGET_IWMMXT.
>>
>> In the new test case the stack is reduced to about 270 bytes, ex
Ping...
On 12/19/16 06:49, Bernd Edlinger wrote:
> Ping...
>
> On 12/12/16 06:59, Bernd Edlinger wrote:
>> Ping...
>>
>> On 12/05/16 14:41, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this was the latest version of my patch:
>&g
Ping...
On 12/27/16 15:12, Bernd Edlinger wrote:
> Ping...
>
> On 12/19/16 06:49, Bernd Edlinger wrote:
>> Ping...
>>
>> On 12/12/16 06:59, Bernd Edlinger wrote:
>>> Ping...
>>>
>>> On 12/05/16 14:41, Bernd Edlinger wrote:
>>>>
On 01/11/17 17:55, Richard Earnshaw (lists) wrote:
>
> Sorry for the delay getting around to this.
>
> I just tried this patch and found that it doesn't apply. Furthermore,
> there's not enough context in the rejected hunks for me to be certain
> which patterns you're trying to fix up.
>
> Could y
On 01/13/17 14:50, Richard Earnshaw (lists) wrote:
> On 18/12/16 12:58, Bernd Edlinger wrote:
>> Hi,
>>
>> this is related to PR77308, the follow-up patch will depend on this one.
>>
>> When trying the split the *arm_cmpdi_insn and *arm_cmpdi_unsigned
>> bef
On 01/13/17 17:10, Bernd Edlinger wrote:
> On 01/13/17 14:50, Richard Earnshaw (lists) wrote:
>> On 18/12/16 12:58, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is related to PR77308, the follow-up patch will depend on this one.
>>>
>
On 01/13/17 19:28, Bernd Edlinger wrote:
> On 01/13/17 17:10, Bernd Edlinger wrote:
>> On 01/13/17 14:50, Richard Earnshaw (lists) wrote:
>>> On 18/12/16 12:58, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this is related to PR77308, the follow
fer space, even if the line
buffer is not yet filled up.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-03-30 Bernd Edlinger
* gcov.c (md5sum_to_hex): Fix output of MD5 hex bytes.
(make_gcov_file_name): Use the canonical path name for generating
On 03/31/17 01:27, Nathan Sidwell wrote:
> On 03/30/2017 04:11 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> I'd like to fix a few buffer overruns I have found in the gcov tools.
>> First I noticed that the -x output contains most of the time "ff" bytes,
>&g
20_util/any/assign/2a.cc is just a
clone of 20_util/any/assign/2.cc with the may_alias
attribute at the right place.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc/cp
2017-04-04 Bernd Edlinger
PR c++/80287
* class.c (fixup_may_alias
On 04/04/17 14:58, Jonathan Wakely wrote:
> On 04/04/17 12:39 +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> I noticed that the already created reference and pointer types
>> are left in an inconsistent state if the may_alias attribute
>> is added to a class, in som
On 04/05/17 00:33, Ville Voutilainen wrote:
> On 5 April 2017 at 00:29, Bernd Edlinger wrote:
>>> The new test doesn't really belong in the libstdc++, does it?
>>>
>>> If this is a bug in the front-end then a reduced version of the test
>>> belongs in t
applied as well,
because otherwise the new attribute will trip several
failures in the libstdc++ testsuite.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
[1] https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00189.htmlgcc
2017-04-05 Bernd Edlinger
On 04/05/17 15:28, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 09:46:09AM +0000, Bernd Edlinger wrote:
>> this is related to the P1 codegen bug PR79671:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>>
>> Therefore I would like to add this now although
&g
On 04/05/17 17:23, Richard Biener wrote:
> On April 5, 2017 4:50:32 PM GMT+02:00, Florian Weimer
> wrote:
>> On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
>>> +@item always_alias
>>> +@cindex @code{always_alias} type attribute
>>> +Same as @code{may_alias}
On 04/05/17 18:08, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 05:03:33PM +0100, Jonathan Wakely wrote:
>>> I wanted to say it behaves mostly like __attribute__((may_alias))
>>> except that may_alias only has an effect on pointers and references
>>> but not when accessing an object directly, (I
On 04/05/17 17:20, Richard Biener wrote:
>> Also, wonder if you need to mark all types containing such arrays,
>> if you couldn't just set that flag in C++ on unsigned char/std::byte
>> arrays (and on anything with that attribute), have that imply alias set
>> 0 on it and then let the rest of alias
On 04/05/17 22:17, Jason Merrill wrote:
> On Wed, Apr 5, 2017 at 1:41 PM, Bernd Edlinger
> wrote:
>> On 04/05/17 17:20, Richard Biener wrote:
>>>> Also, wonder if you need to mark all types containing such arrays,
>>>> if you couldn't just set th
On 04/05/17 19:22, Bernd Edlinger wrote:
> On 04/05/17 18:08, Jakub Jelinek wrote:
>
> Yes, exactly. I really want to reach the deadline for gcc-7.
> Fixing the name is certainly the most important first step,
> and if everybody agrees on "typeless_storage", for th
On 04/06/17 09:55, Richard Biener wrote:
> On Thu, 6 Apr 2017, Jakub Jelinek wrote:
>
>> On Thu, Apr 06, 2017 at 09:47:10AM +0200, Richard Biener wrote:
>>> @@ -955,6 +960,7 @@ get_alias_set (tree t)
>>> Just be pragmatic here and make sure the array and its element
>>> type get the sam
On 04/06/17 16:17, Florian Weimer wrote:
>> Here is what I want to write in the doc:
>>
>> @item typeless_storage
>> @cindex @code{typeless_storage} type attribute
>> A type declared with this attribute behaves like a character type
>> with respect to aliasing semantics.
>> This is attribute is sim
On 04/06/17 19:47, Florian Weimer wrote:
> On 04/06/2017 07:39 PM, Bernd Edlinger wrote:
>> On 04/06/17 16:17, Florian Weimer wrote:
>>>> Here is what I want to write in the doc:
>>>>
>>>> @item typeless_storage
>>>> @cindex @code{typele
On 04/06/17 20:19, Florian Weimer wrote:
>
> I don't know what your patch does, but your proposed documentation does
> not make this valid because “declared as char” is still not “having no
> declared type”. Or put differently, “behaves like a character type” is
> not what we actually want here.
>
On 04/06/17 21:05, Florian Weimer wrote:
> On 04/06/2017 08:49 PM, Bernd Edlinger wrote:
>
>> For instance how do you "declare an object without a declared type"?
>
> malloc and other allocation functions return pointers to objects without
> a declared type.
>
T
On 04/06/17 21:14, Richard Biener wrote:
> On April 6, 2017 7:39:14 PM GMT+02:00, Bernd Edlinger
> wrote:
>> On 04/06/17 16:17, Florian Weimer wrote:
>>>> Here is what I want to write in the doc:
>>>>
>>>> @item typeless_storage
>>>>
On 04/05/17 23:02, Bernd Edlinger wrote:
> On 04/05/17 19:22, Bernd Edlinger wrote:
>> On 04/05/17 18:08, Jakub Jelinek wrote:
>>
>> Yes, exactly. I really want to reach the deadline for gcc-7.
>> Fixing the name is certainly the most important first step,
&g
On 04/06/17 09:47, Richard Biener wrote:
> On Wed, 5 Apr 2017, Bernd Edlinger wrote:
>
>> On 04/05/17 19:22, Bernd Edlinger wrote:
>>> On 04/05/17 18:08, Jakub Jelinek wrote:
>>>
>>> Yes, exactly. I really want to reach the deadline for gcc-7.
>>>
901 - 1000 of 1395 matches
Mail list logo
