On 04/07/17 08:47, Richard Biener wrote:
> On Thu, 6 Apr 2017, Bernd Edlinger wrote:
>
>> 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 decl
On 04/07/17 08:54, Richard Biener wrote:
> On Thu, 6 Apr 2017, Bernd Edlinger wrote:
>> I think get_alias_set(t) will return 0 for typeless_storage
>> types, and therefore has_zero_child will be set anyway.
>> I think both mean the same thing in the end, but it depends on
>
On 04/07/17 17:10, Richard Biener wrote:
> On April 7, 2017 3:37:30 PM GMT+02:00, Bernd Edlinger
> wrote:
>> On 04/07/17 08:54, Richard Biener wrote:
>>> On Thu, 6 Apr 2017, Bernd Edlinger wrote:
>>>> I think get_alias_set(t) will return 0 for typeless_
On 04/12/17 17:58, Yvan Roux wrote:
> Hi,
>
> On 20 February 2017 at 18:53, Bruce Korb wrote:
>> On 02/18/17 01:01, Bernd Edlinger wrote:
>>> On 02/18/17 00:37, Bruce Korb wrote:
>>>> On 02/06/17 10:44, Bernd Edlinger wrote:
>>>>> I tested t
Hi Yvan,
On 04/14/17 10:24, Yvan Roux wrote:
> Hi Bernd,
>
> On 14 April 2017 at 06:18, Bernd Edlinger wrote:
>> On 04/12/17 17:58, Yvan Roux wrote:
>>> Hi,
>>>
>>> On 20 February 2017 at 18:53, Bruce Korb wrote:
>>>> On 02/18/17 01:01, Ber
On 04/14/17 12:29, Bernd Edlinger wrote:
> Hi RMs:
>
> I am sorry that this happened so close to the imminent gcc-7 release
> date.
>
> To my best knowledge it would be fine to apply this update patch on the
> trunk: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00649.html
Ping...
for this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01351.html
On 01/18/17 16: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 Earnshaw (lists) wrote:
>>>
runk?
Thanks
Bernd.
2017-04-18 Bernd Edlinger
* configure.ac (SYSTEM_HEADER_DIR, BUILD_SYSTEM_HEADER_DIR,
target_header_dir): Set correctly.
* configure: Regenerated.
* Makefile.in (BUILD_SYSTEM_HEADER_DIR): New make variabe.
(LIMITS_H_TEST, if_multiarch, stmp-fixinc): Use BUILD_SYSTEM_HE
warning, it revealed quite a few
places where bogus sizeof divisions were used in our testsuite.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2017-04-20 Bernd Edlinger
* doc/invoke.texi: Document the -Wsizeof-pointer-div warning.
gcc/c
the gcov tool.
So I would like to add a -fprofile-abs-path option that
forces absolute path names in gcno files, which allows gcov
to get the true canonicalized source name.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2017-04-21 Bernd Edlinger
x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-04-21 Bernd Edlinger
* c-common.c (c_type_hasher): Remove.
(type_hash_table): Remove.
(c_common_get_alias_set): Remove unreachable code.
Index: gcc/c-family/
On 04/21/17 21:50, Joseph Myers wrote:
> On Fri, 21 Apr 2017, Bernd Edlinger wrote:
>
>> So I would like to add a -fprofile-abs-path option that
>> forces absolute path names in gcno files, which allows gcov
>> to get the true canonicalized source name.
>
> I don&
On 04/22/17 01:50, Martin Sebor wrote:
> On 04/20/2017 02:35 PM, Bernd Edlinger wrote:
>> Hi!
>>
>>
>> This implements a new -Wall enabled warning for a rather common, but
>> completely wrong way to compute an array size by dividing the
>> sizeof(pointer)
target hook?
Patch works at least for x86_64 and arm.
Is it OK for trunk?
Bernd.
2017-04-23 Bernd Edlinger
rtl-optimizatoin/79286
* ira.c (update_equiv_regs): Revert to using may_tap_p again.
* rtlanal.c (rtx_addr_can_trap_p_1): SYMBOL_REF_FUNCTION_P can never
trap
On 04/24/17 09:00, Richard Biener wrote:
> On Fri, 21 Apr 2017, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This removes some dead and unreachable code in c_common_get_alias_set:
>> Because cc1 was recently changed to be only called with one file at a
>> ti
On 04/26/17 12:07, Martin Liška wrote:
> On 04/26/2017 12:05 PM, Martin Liška wrote:
>> Received as HTML from Kelvin:
>>
>> I have reviewed some of the implementation details for pthread_mutex_init
>> and pthread_mutex_lock, and have confirmed that ppc64 does use memset to
>> initialize the entir
On 04/28/17 00:52, Martin Sebor wrote:
>>> I suggest avoiding "element size" because the pointed-to argument
>>> need not be an array. Mentioning the types should help users better
>>> understand the problem (especially in C++ where types are often
>>> obscured by layers of templates). It might a
On 04/28/17 17:29, Martin Sebor wrote:
> On 04/28/2017 08:12 AM, Bernd Edlinger wrote:
>>
>> Do you want me to change the %qT format strings to %T ?
>
> Yes, with the surrounding %< and %> the nested directives should
> use the unquoted forms, otherwise the printer w
On 04/28/17 18:48, Jeff Law wrote:
> On 04/23/2017 05:54 AM, Bernd Edlinger wrote:
>> Hi Jeff,
>>
>>
>> this patch tries to fix the handling of pic_offset_rtx +
>> const(unspec(symbol_ref)+ const_int) in may_trap_p,
>> and restores the original state of affa
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:
>
>
> On 04/21/17 21:50, Joseph Myers wrote:
>> On Fri, 21 Apr 2017, Bernd Edlinger wro
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+const and see what happens.
>>
>> However the SYMBOL_REF_FUNC
On 04/28/17 21:14, 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
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+const and see what happens.
>>
>> However the SYMBOL_REF_FUNC
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:
>> On 01/13/17 19:28, Bernd Edlinger wrote:
>>> On 01/13/17 17:10, Bernd Edlin
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 target has no neon or iwmmxt.
Thanks
Bernd.
On 11/28/16 20:42, Bernd Edlinger
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_unsigned
> also at split1 except for TARGET_NEON and TARGET_IWMMXT.
>
> In the new test case the s
On 05/01/17 17:54, Jason Merrill wrote:
> On Fri, Apr 28, 2017 at 1:05 PM, Bernd Edlinger
> wrote:
>> On 04/28/17 17:29, Martin Sebor wrote:
>>> On 04/28/2017 08:12 AM, Bernd Edlinger wrote:
>>>>
>>>> Do you want me to change the %qT format strings to
On 09/13/17 19:06, Joseph Myers wrote:
> What does this warning do in cases where a type has different alignments
> inside and outside structs? I'm thinking of something like
>
> struct s { long long x; } *p;
> /* ... */
> (long long *)p
>
> on 32-bit x86 - where long long's preferred alignment
On 09/13/17 22:03, Joseph Myers wrote:
> On Wed, 13 Sep 2017, Bernd Edlinger wrote:
>
>> On 09/13/17 19:06, Joseph Myers wrote:
>>> What does this warning do in cases where a type has different alignments
>>> inside and outside structs? I'm thinking of somethin
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 like to ad
Hi,
ping... for the documentation part.
Thanks,
Bernd.
On 09/06/17 17:31, Kyrill Tkachov wrote:
>
> On 06/09/17 14:17, 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:5
> Greetings,
>
> I don't have write access so can someone commit this bug fix as it
> fixes,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188.
>
> Author: Nicholas Krause
> Date: Fri Sep 29 11:39:46 2017 -0400
>
>This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80
On 09/29/17 20:22, nick wrote:
>
>
> On 2017-09-29 01:48 PM, Bernd Edlinger wrote:
>> > Greetings,
>> >
>> > I don't have write access so can someone commit this bug fix as it
>> > fixes,
>> > https://gcc.gnu.org/bugzilla/s
Hi,
I think this might be a false positive tsan warning.
Maybe tsan does not see why a desctructor function
can not execute before the last detached thread
terminates.
I created a small test case that receives a warning
which is similar to the one you tried to fix with your
patch:
cat test.c
#in
On 10/01/17 15:41, Thomas Koenig wrote:
> Am 01.10.2017 um 10:59 schrieb Bernd Edlinger:
>> maybe there is a way how you could explicitly join
>> all running threads?
>
> Yes, that seems to do the trick. Thanks!
>
Oh, that is really very surprising...
I believe that all
line in libgo, but that is only
a quick hack which I only did to make the boot-strap with
all languages succeed.
I'm not sure if this warning may be a bit too strict, but I think
so far it just triggered on rather questionable code.
Thoughts?
Bernd.
gcc:
2017-10-03 Bernd Edl
On 10/05/17 02:24, Eric Gallager wrote:
> Sorry if this is a stupid question, but could you explain how this
> warning is different from -Wbad-function-cast? Something about direct
> calls to functions vs. passing them as function pointers?
No, it is not :)
-Wbad-function-cast is IMHO a strange l
On 10/03/17 23:34, Joseph Myers wrote:
> On Tue, 3 Oct 2017, Bernd Edlinger wrote:
>
>> invalid, also if both function types have a non-null TYPE_ARG_TYPES
>> I would say this deserves a warning. As an exception I have
>
> I'm not convinced by the TYPE_ARG_TYPES
Hi!
This fixes the c-pretty-printing of variadic function types by
adding ", ..." to the output of the function parameters.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
c-family:
2017-10-05 Bernd Edlinger
* c-pret
On 10/05/17 18:16, Martin Sebor wrote:
> On 10/03/2017 01:33 PM, Bernd Edlinger wrote:
>>
>> I'm not sure if this warning may be a bit too strict, but I think
>> so far it just triggered on rather questionable code.
>>
>> Thoughts?
>
> My in
On 10/05/17 18:16, Martin Sebor wrote:
> In my (very quick) tests the warning appears to trigger on all
> strictly incompatible conversions, even if they are otherwise
> benign, such as:
>
> int f (const int*);
> typedef int F (int*);
>
> F* pf1 = f; // -Wincompatible-pointer-type
On 10/06/17 17:43, Martin Sebor wrote:
> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>> On 10/05/17 18:16, Martin Sebor wrote:
>>> In my (very quick) tests the warning appears to trigger on all
>>> strictly incompatible conversions, even if they are otherwise
>>
On 10/06/17 22:50, Jeff Law wrote:
> On 10/06/2017 09:43 AM, Martin Sebor wrote:
>> On 10/06/2017 07:25 AM, Bernd Edlinger wrote:
>>> On 10/05/17 18:16, Martin Sebor wrote:
>>>> In my (very quick) tests the warning appears to trigger on all
>>>> strictly
bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2017-10-06 Bernd Edlinger
* doc/invoke.texi: Document -Wcast-function-type.
* recog.h (stored_funcptr): Change signature.
* tree-dump.c (dump_node): Avoid warning.
On 10/09/17 18:44, Martin Sebor wrote:
> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> I think I have now something useful, it has a few more heuristics
>> added, to reduce the number of false-positives so that it
>> is able to find real bugs, for inst
On 10/09/17 20:34, Martin Sebor wrote:
> On 10/09/2017 11:50 AM, Bernd Edlinger wrote:
>> On 10/09/17 18:44, Martin Sebor wrote:
>>> On 10/07/2017 10:48 AM, Bernd Edlinger wrote:
>>>> Hi!
>>>>
>>>> I think I have now something useful, it has
On 10/09/17 15:02, Richard Earnshaw (lists) wrote:
> On 06/09/17 14:17, Bernd Edlinger wrote:
>> Index: gcc/doc/rtl.texi
>> ===
>> --- gcc/doc/rtl.texi (revision 251752)
>> +++ gcc/doc/rtl.texi (working c
BUILD_SYSTEM_HEADER_DIR.
I tested this change with different arm-linux-gnueabihf cross
compilers, and verified that mkheaders still works on the host system.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2017-02-06 Bernd Edlinger
* Makefile.in
On 02/18/17 00:37, Bruce Korb wrote:
> On 02/06/17 10:44, Bernd Edlinger wrote:
>> I tested this change with different arm-linux-gnueabihf cross
>> compilers, and verified that mkheaders still works on the host system.
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux
nconditionally.
I've verified that the header compiles on an eCos cross compiler.
Boot-strapped and regression-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.2016-03-08 Bernd Edlinger
* include/Makefile.am (install-freestanding-headers): Add
concept_check.h and move
Ping...
Hi,
when the free-standing libstdc++-headers are installed, the C++ header
file does not always compile, because it includes and this
includes under certain conditions (__cplusplus >= 201103L &&
ATOMIC_INT_LOCK_FREE > 1) the header file
but that fails to compile because it needs which
On 19.03.2016 21:29, Marc Glisse wrote:
> On Tue, 5 Jan 2016, Richard Biener wrote:
>> On January 5, 2016 2:20:42 PM GMT+01:00, Bernd Edlinger
>> wrote:
>>> On 05.01.2016 13:58, Bernd Schmidt wrote:
>>>> On 01/05/2016 09:44 AM, Bernd Edlinger wrote:
>>>
On 20.03.2016 11:03, Marc Glisse wrote:
> On Sun, 20 Mar 2016, Bernd Edlinger wrote:
>
>>>>>>> So I looked for a way to disable the asm code, and found it can be
>>>>>>> done, but differently than for in-tree gmp. See the attached patch.
>>>
Hi,
I am pinging for this patch, which addresses an admittedly minor regression
for free-standing libstdc++ due to changed c++11 default settings. The proposed
patch does only change the free-standing install rule, and has therefore no
impact
on other configurations.
https://gcc.gnu.org/ml/lib
On 22.03.2016 15:36, Jonathan Wakely wrote:
> On 22/03/16 07:10 +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> I am pinging for this patch, which addresses an admittedly minor
>> regression
>> for free-standing libstdc++ due to changed c++11 default settings.
>>
On 22.03.2016 20:10, Jonathan Wakely wrote:
> On 22/03/16 18:29 +0000, Bernd Edlinger wrote:
>> Yes. Maybe changing concept_check.h would be better, because
>> I see 3 different instances of bits/c++config.h:
>>
>> $prefix/arm-eabi/include/c++/6.0.0/arm-eabi/fpu/bits
Boot-strapped and regression tested on x86_64-pc-linux-gnu, with different
gmp versions including the latest snapshot.
I have additionally built arm cross compilers, which was not working before.
Is this OK for trunk?
Thanks
Bernd.2016-03-28 Bernd Edlinger
PR bootstrap/
On 29.03.2016 at 10:32, Richard Biener wrote:
> On Mon, Mar 28, 2016 at 2:44 PM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> as described in the tracker we have bootstrap problems with in-tree gmp-6.1.0
>> on certain targets, and also a linker issue with check-mp
+ /* If this is a reference from symbol itself and there are no aliases, we
+ may be sure that the symbol was not interposed by soemthing else because
+ the symbol itself would be unreachable otherwise. */
typo: s/soemthing/something/
Bernd.
re/
before this patch can be applied of course (I don't know how to).
Thanks
Bernd.2016-04-26 Bernd Edlinger
* configure.ac (mpfr): Remove pre-3.1.0 compatibility.
* configure: Regenerated.
* Makefile.def (gmp): Explicitly disable assembler.
(mpfr): Adjust li
On 26.04.2016 20:29, Jakub Jelinek wrote:
> On Tue, Apr 26, 2016 at 06:23:17PM +0000, Bernd Edlinger wrote:
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>
> I'm not saying we shouldn't bump the min
On 26.04.2016 20:39, Marc Glisse wrote:
> On Tue, 26 Apr 2016, Bernd Edlinger wrote:
>
>> as we all know, it's high time now to adjust the minimum supported
>> gmp/mpfr/mpc versions for gcc-7.
>>
>> So this attached patch is now targeting at only supporting
On 09/07/16 22:04, Joseph Myers wrote:
> On Wed, 7 Sep 2016, Bernd Edlinger wrote:
>
>> interesting. I just tried the test case from PR 77330 with _Decimal128.
>> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
>> gcc-7.0.0.
>
> I che
Maybe one last comment on your patch itself, could you please move
the unit test cases in extra unit test files, or even a self-test tree?
Thanks
Bernd.2016-08-04 Bernd Edlinger
PR rtl-optimization/71779
* emit-rtl.c (set_reg_attrs_from_value): Only propagate REG_POINTER,
if the value was sign
On 09/08/16 11:35, Florian Weimer wrote:
> On 09/07/2016 08:32 PM, Bernd Edlinger wrote:
>> interesting. I just tried the test case from PR 77330 with _Decimal128.
>> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
>> gcc-7.0.0.
>
> Recent
Hi,
just a nit:
+Defined to the widths of the corresponding types. They exist to make
+the implementations of @file{limits.h} and @file{stdint.h} make
+correctly.
Defined to the bit widths ...
They exist to make the implementations of ... behave correctly.
Bernd.
stop somewhere.
Bootstrapped and reg-tested on x86_64-pc-linux.gnu
Is it OK for trunk?
Thanks
Bernd.2016-09-09 Bernd Edlinger
* doc/tm.texi.in (INITIAL_FRAME_POINTER_OFFSET): Remove.
(ELIMINABLE_REGS, TARGET_CAN_ELIMINATE,
INITIAL_ELIMINATION_OFFSET) : Update document
On 09/10/16 01:11, Jeff Law wrote:
>> First the good news. The unit test does actually work, but not only
>> on aarch even without -mabi=ilp32, but also on i386. All that's
>> missing is a check that we don't get a reg/f here:
> Sweet. This starts to touch on some of those unanswered questions
Hi,
the following C/C++ FE warning patches are still waiting for review:
20 Aug 2016: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01463.html
[PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)
4 Sep 2016: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00155.html
[PATCHv2] Ad
FYI: I have a patch for the aarch64 regression here:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=39600
It passes bootstrap and reg-testing on x86_64-linux-gnu.
Also the mentioned aarch64 and powerpc test cases
pass manually in a cross-compiler, but I cannot do the
boot-strap on powerpc or aarc
Hi,
the attached patch boot-straps and reg-tests cleanly
on x86_64-pc-linux-gnu, powerpc and aarch64 targets.
Is it OK for trunk?
Thanks
Bernd.
2016-09-12 Bernd Edlinger
PR rtl-optimization/77289
* lra-constraints.c (get_final_hard_regno): Removed.
(get_hard_regno): Add new parameter
On 09/12/16 21:30, Jeff Law wrote:
> On 09/02/2016 12:53 PM, Bernd Edlinger wrote:
>> Hi!
>>
>> As reported in PR77434 and PR77421 there should be a warning for
>> suspicious uses of conditional expressions with non-boolean arguments.
>>
>> This warning
On 09/12/16 22:08, Jeff Law wrote:
> On 09/12/2016 02:00 PM, Bernd Edlinger wrote:
>
>> Yes, I will update the patch accordingly.
>>
>> I agree, a statement like "if (x ? 0 : 2)" can be called suspicious as
>> well, even if the result of x is not ignor
On 09/12/16 23:45, Jeff Law wrote:
> On 09/12/2016 07:43 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> the attached patch boot-straps and reg-tests cleanly
>> on x86_64-pc-linux-gnu, powerpc and aarch64 targets.
>>
>> Is it OK for trunk?
> Unfortunately, there&
e cleaned up.
Bootstrap and reg-test with all languages on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
gcc:
2016-09-14 Bernd Edlinger
PR c++/77434
* doc/invoke.texi: Document -Wcond-in-bool-context.
* gensupport.c (TRISTATE_AND, TRISTATE_OR,
TRIST
On 09/14/16 18:37, Jason Merrill wrote:
> On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger
> wrote:
>> The other false positive was in dwarf2out, where we have this:
>>
>> ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integer
>> constants in boolea
On 09/14/16 19:40, Steve Kargl wrote:
> On Wed, Sep 14, 2016 at 04:10:46PM +0000, Bernd Edlinger wrote:
>>
>> fortran:
>> 2016-09-14 Bernd Edlinger
>>
>> PR c++/77434
>> * simplify.c (gfc_simplify_repeat): Fix a warni
... resent, because message apparently bounced.
On 09/14/16 21:22, Bernd Edlinger wrote:
> On 09/14/16 20:11, Jason Merrill wrote:
>>>
>>> Yes. The reasoning I initially had was that it is completely
>>> pointless to have something of the form "if (x ? 1 : 2)&q
On 09/15/16 17:44, Jeff Law wrote:
> On 09/14/2016 12:11 PM, Jason Merrill wrote:
>>
>> I think we could have both, where the weaker form is part of -Wall and
>> people can explicitly select the stronger form.
> That's been a fairly standard way to handle this kind of thing. It
> works for me.
>
>
On 09/15/16 18:23, Jeff Law wrote:
> On 09/15/2016 10:00 AM, Bernd Edlinger wrote:
>> On 09/15/16 17:44, Jeff Law wrote:
>>> On 09/14/2016 12:11 PM, Jason Merrill wrote:
>>>>
>>>> I think we could have both, where the weaker form is part of -Wall and
>
On 09/15/16 21:54, Jason Merrill wrote:
> On Thu, Sep 15, 2016 at 1:42 PM, Joseph Myers wrote:
>> On Thu, 15 Sep 2016, Bernd Edlinger wrote:
>>
>>> So level 1 could be enabled with -Wall and level 2 could be enabled
>>> with -pedantic and/or -Wpedantic.
>
On 09/17/16 22:29, Jan-Benedict Glaw wrote:
> On Fri, 2016-09-09 21:40:38 +0000, Bernd Edlinger
> wrote:
>> Hi,
>>
>> I think it is time to remove support for INITIAL_FRAME_POINTER_OFFSET, which
>> is no longer
>> used by any target today. This remo
?
Thanks
Bernd.
gcc:
2016-09-18 Bernd Edlinger
PR tree-optimization/77550
* tree-vect-stmts.c (create_array_ref): Change parameters.
(get_group_alias_ptr_type): New function.
(vectorizable_store, vectorizable_load): Use get_group_alias_ptr_type.
testsuite:
2016
Hi,
> when expanding code for
> struct a {short a,b,c,d;} *a;
> a->c;
>
> we first produce correct BLKmode MEM rtx representing the whole
> structure *a,
> then we use adjust_address to turn it into HImode MEM and finally
> extract_bitfield is used to offset it by 32 bits to get correct va
On 09/19/16 11:28, Richard Biener wrote:
> On Sun, 18 Sep 2016, Jan Hubicka wrote:
>
>>> Hi,
>>>
>>> > when expanding code for
>>> > struct a {short a,b,c,d;} *a;
>>> > a->c;
>>> >
>>> > we first produce correct BLKmode MEM rtx representing the whole
>>> > structure *a,
>>> > then we
On 09/19/16 16:23, Richard Biener wrote:
> On 19/09/16 15:49, Bernd Edlinger wrote:
>> On 09/19/16 11:28, Richard Biener wrote:
>>> On Sun, 18 Sep 2016, Jan Hubicka wrote:
>>>
>>>>> Hi,
>>>>>
>>>>>> when
On 09/19/16 11:25, Richard Biener wrote:
> On Sun, 18 Sep 2016, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this PR shows that in vectorizable_store and vectorizable_load
>> as well, the vector access always uses the first dr as the alias
>> type for the whole access.
On 09/19/16 21:17, Jason Merrill wrote:
> On 09/15/2016 05:19 AM, Bernd Edlinger wrote:
>> + if (warn_int_in_bool_context)
>> +{
>> + tree val1 = fold_for_warn (TREE_OPERAND (expr, 1));
>> + tree val2 = fold_for_warn (TREE_OPERAND (expr, 2));
&g
On 09/19/16 22:19, Jeff Law wrote:
> On 09/15/2016 04:29 AM, Tom de Vries wrote:
>> On 31/08/16 07:42, Tom de Vries wrote:
>>> On 30/08/16 11:38, Bernd Edlinger wrote:
>>>> On 08/30/16 10:21, Tom de Vries wrote:
>>>>> On 29/08/16 18:43, Bernd Edlinger
On 09/19/16 21:51, Jeff Law wrote:
> On 09/15/2016 03:19 AM, Bernd Edlinger wrote:
>> On 09/14/16 20:11, Jason Merrill wrote:
>>>> >>
>>>> >> Yes. The reasoning I initially had was that it is completely
>>>> >> pointless to have s
On 09/19/16 23:51, Jeff Law wrote:
> On 09/17/2016 05:29 PM, Bernd Edlinger wrote:
>> On 09/17/16 22:29, Jan-Benedict Glaw wrote:
>>> On Fri, 2016-09-09 21:40:38 +0000, Bernd Edlinger
>>> wrote:
>>>> Hi,
>>>>
>>>> I think it is time
On 09/20/16 13:29, Kyrill Tkachov wrote:
>
> arm bootstrap is now failing:
> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in
> boolean context [-Werror=int-in-bool-context]
> : (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \
> ~~
On 09/20/16 16:20, Kyrill Tkachov wrote:
>
> On 20/09/16 15:11, Bernd Edlinger wrote:
>> On 09/20/16 13:29, Kyrill Tkachov wrote:
>>> arm bootstrap is now failing:
>>> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in
>>> boole
On 09/20/16 09:41, Richard Biener wrote:
> On Mon, 19 Sep 2016, Bernd Edlinger wrote:
>
>> On 09/19/16 11:25, Richard Biener wrote:
>>> On Sun, 18 Sep 2016, Bernd Edlinger wrote:
>>>
>>>> Hi,
>>>>
>>>> this PR shows that in vector
On 09/20/16 18:12, Kyrill Tkachov wrote:
>
> On 20/09/16 16:30, Bernd Schmidt wrote:
>> On 09/20/2016 05:18 PM, Jeff Law wrote:
I assume HARD_FRAME_POINTER_REGNUM is never zero.
>>> It could be zero. It's just a hard register number. No target has the
>>> property that its hard frame pointer
On 09/20/16 18:29, Kyrill Tkachov wrote:
>>
>> I'll try bootstrapping and testing this change on
>> arm-none-linux-gnueabihf.
>>
>
> ... and I'm hitting the same issue in sel-sched.c:
> if (fixed_regs[regno]
> || global_regs[regno]
> || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && f
On 09/20/16 16:51, Jason Merrill wrote:
> On Tue, Sep 20, 2016 at 10:11 AM, Bernd Edlinger
> wrote:
>> On 09/20/16 13:29, Kyrill Tkachov wrote:
>>>
>>> arm bootstrap is now failing:
>>> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants
On 09/21/16 16:38, Richard Earnshaw (lists) wrote:
> On 20/09/16 16:30, Bernd Schmidt wrote:
>> On 09/20/2016 05:18 PM, Jeff Law wrote:
I assume HARD_FRAME_POINTER_REGNUM is never zero.
>>> It could be zero. It's just a hard register number. No target has the
>>> property that its hard frame
On 09/21/16 17:00, Jason Merrill wrote:
> On 09/20/2016 02:40 PM, Bernd Edlinger wrote:
>> On 09/20/16 16:51, Jason Merrill wrote:
>>> On Tue, Sep 20, 2016 at 10:11 AM, Bernd Edlinger
>>> wrote:
>>>> I think I will have to suppress the warning if the
On 09/21/16 21:03, Jason Merrill wrote:
> On Wed, Sep 21, 2016 at 11:43 AM, Bernd Edlinger
> wrote:
>> Yes. I think that goes in the right direction,
>> but it does not work yet.
>>
>> #define XXX (a ? 2 : 3)
>>
>> if (XXX) // prints a warning, b
1001 - 1100 of 1395 matches
Mail list logo
