[PATCH] Change default for --param allow-...-data-races to off

2014-06-19 Thread Bernd Edlinger
for trunk? Thanks Bernd. gcc/ChangeLog: 2014-06-19 Bernd Edlinger bernd.edlin...@hotmail.de Set default for --param allow-...-data-races to off. * params.def (PARAM_ALLOW_LOAD_DATA_RACES, PARAM_ALLOW_STORE_DATA_RACES

[PATCH] Remove bogus include path with in-tree cloog

2014-06-20 Thread Bernd Edlinger
-strapped and regression-tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2014-06-20 Bernd Edlinger bernd.edlin...@hotmail.de Fix include path for in-tree cloog. * config/cloog.m4 (CLOOG_INIT_FLAGS): Remove bogus include path

[PATCH] Fix forwporp pattern (T)(P + A) - (T)P - (T)A

2014-06-22 Thread Bernd Edlinger
and regression-tested on x86_64-linux-gnu with all languages, including Ada. OK for trunk? Thanks Bernd. gcc/ChangeLog: 2014-06-22 Bernd Edlinger bernd.edlin...@hotmail.de * tree-ssa-forwprop.c (associate_plusminus): For widening conversions

RE: [PATCH] Change default for --param allow-...-data-races to off

2014-06-23 Thread Bernd Edlinger
Hi, On Fri, 20 Jun 2014 13:44:18, Martin Jambor wrote: Hi, On Thu, Jun 19, 2014 at 06:18:47PM +0200, Bernd Edlinger wrote: Hi, from a recent discussion on g...@gcc.gnu.org I have learned that the default of --param allow-store-data-races is still 1, and it is causing problems

RE: [PATCH] Change default for --param allow-...-data-races to off

2014-06-23 Thread Bernd Edlinger
Hi Martin, Well actually, I am not sure if we ever wanted to have a race condition here. Have you seen any impact of --param allow-store-data-races on any benchmark? It's trivially to write one. The only pass that checks the param is tree loop invariant motion and it does that when it

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P - (T)A

2014-06-23 Thread Bernd Edlinger
Hi, On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, I noticed that several testcases in the GMP-4.3.2 test suite are failing now which did not happen with GCC 4.9.0. I debugged the first one, mpz

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P - (T)A

2014-06-23 Thread Bernd Edlinger
Hi, On Mon, 23 Jun 2014 10:27:59, Jeff Law wrote: On 06/22/14 01:14, Bernd Edlinger wrote: Hi, I noticed that several testcases in the GMP-4.3.2 test suite are failing now which did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and found the file mpn/generic

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P - (T)A

2014-06-23 Thread Bernd Edlinger
Hi, On Mon, 23 Jun 2014 19:12:47, Richard Biener wrote: On Mon, Jun 23, 2014 at 4:28 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Mon, 23 Jun 2014 10:40:53, Richard Biener wrote: On Sun, Jun 22, 2014 at 9:14 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, I

RE: [PATCH] Fix forwporp pattern (T)(P + A) - (T)P - (T)A

2014-06-23 Thread Bernd Edlinger
Hi, On Mon, 23 Jun 2014 16:22:13, Eric Botcazou wrote: I noticed that several testcases in the GMP-4.3.2 test suite are failing now which did not happen with GCC 4.9.0. I debugged the first one, mpz/convert, and found the file mpn/generic/get_str.c was miscompiled. mpn/get_str.c.132t.dse2:

[PATCH] Fix forwprop pattern (T)(P + A) - (T)P - (T)A, Part 1

2014-06-24 Thread Bernd Edlinger
point types. Thus _Sat is only allowed with _Frac or _Accum. I have not seen anything different, for instance a vector, with saturation yet. OK for trunk after boot-strap regression-test? Thanks Bernd. gcc/ChangeLog: 2014-06-24 Bernd Edlinger bernd.edlin

[PATCH] Fix forwprop pattern (T)(P + A) - (T)P - (T)A, Part 2

2014-06-25 Thread Bernd Edlinger
for trunk? Thanks Bernd. 2014-06-25 Bernd Edlinger bernd.edlin...@hotmail.de * tree-ssa-forwprop.c (associate_plusminus): For widening conversions check for undefined overflow in (T)(P + A) - (T)P - (T)A. Issue a strict overflow

RE: [PATCH] Change default for --param allow-...-data-races to off

2014-06-26 Thread Bernd Edlinger
Hi, On Thu, 26 Jun 2014 08:43:46, Richard Biener wrote: On June 26, 2014 12:03:21 AM CEST, Martin Jambor mjam...@suse.cz wrote: Hi, On Wed, Jun 25, 2014 at 03:14:31PM -0600, Jeff Law wrote: On 06/24/14 14:19, Martin Jambor wrote: On Mon, Jun 23, 2014 at 03:35:01PM +0200, Bernd Edlinger wrote

Fix PR 61461: -fdump-rtl-all-slim causes ICE

2014-07-14 Thread Bernd Edlinger
by semicolons. Boot-strapped and regression-tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2014-07-15 Bernd Edlinger bernd.edlin...@hotmail.de PR rtl-optimization/61461 * sched-vis.c (print_pattern) ADDR_VEC, ADDR_DIFF_VEC: Fixed

RE: [PING**3] [PATCH] Fix PR ipa/61190, 2nd edition‏

2014-11-12 Thread Bernd Edlinger
Ping... From: bernd.edlin...@hotmail.de To: gcc-patches@gcc.gnu.org CC: richard.guent...@gmail.com; hubi...@ucw.cz Subject: RE: [PING**2] [PATCH] Fix PR ipa/61190, 2nd edition‏ Date: Mon, 27 Oct 2014 09:23:41 +0100 Ping again... Thanks.

RE: [PATCH, committed] Update Automake files

2014-11-20 Thread Bernd Edlinger
Hello Jan-Benedict, Hi! This patch updates the files taken from Automake. Committed. MfG, JBG the updated version of missing will confuse the gmp-4.3.2 configure script if it is installed in-tree with contrib/download_prerequisites and flex is not installed: ... checking readline

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2014-11-21 Thread Bernd Edlinger
Aehm Kirill, excuse me please, but if I do autogen Makefile.def I get this from svn diff Index: Makefile.in === --- Makefile.in    (revision 217890) +++ Makefile.in    (working copy) @@ -35238,9 +35238,6 @@ $(SHELL)

RE: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2014-11-21 Thread Bernd Edlinger
Hi Ilya, On Fri, 21 Nov 2014 21:44:40, Ilya Verbin wrote: Hi, On 21 Nov 19:19, Bernd Edlinger wrote: so, did you really regenerate Makefile.in in that patch, or am I missing something ? You're right. This patch was rebased so many times, that we may forget to regenerate it before

[PATCH] Work around in-tree gmp configure problems

2014-11-22 Thread Bernd Edlinger
. 2014-11-22 Bernd Edlinger bernd.edlin...@hotmail.de * Makefile.def (module=gmp): Work around in-tree gmp configure bug with missing flex. * Makefile.in: Regenerated. patch-gmp.diff Description: Binary data

RE: [PING**4] [PATCH] Fix PR ipa/61190, 2nd edition‏

2014-11-24 Thread Bernd Edlinger
cgraph_node, which inherits from symtab_node. Both functions are not declared virtual. Is that what's intended? Usually this could lead to errors, or at least some serious compiler warnings. Thanks Bernd. 2014-10-07 Bernd Edlinger bernd.edlin

RE: [PATCH] Work around in-tree gmp configure problems

2014-11-24 Thread Bernd Edlinger
script, and previously that emitted an error message and created a dummy lex.yy.c, The new version of that script does no longer create any lex.yy.c. [...] 2014-11-22 Bernd Edlinger bernd.edlin...@hotmail.de * Makefile.def (module=gmp): Work around in-tree gmp configure bug with missing flex

RE: [PATCH] Fix PR ipa/61190, updated

2014-11-25 Thread Bernd Edlinger
patch for review. Boot-strapped and regression tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. Can you, please, send the updated patch? Sorry for late review, Honza 2014-11-25 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/61190

[PATCH] Fix PR preprocessor/58893 access to uninitialized memory

2014-09-26 Thread Bernd Edlinger
Hi, this patch fixes PR58893, which is an access to uninitialized memory, which may or may not crash in linemap_resolve_location, or just print error messages with bogus location. When the first -include file is processed we have the case, where pfile-cur_token == pfile-cur_run-base, this is

FW: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory

2014-09-26 Thread Bernd Edlinger
-Strapped and Regression-tested on x86_64-linux-gnu Ok for trunk? Thanks Bernd. 2014-09-26 Bernd Edlinger bernd.edlin...@hotmail.de PR preprocessor/58893 * errors.c (cpp_diagnostic): Fix possible out of bounds access

RE: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory

2014-09-27 Thread Bernd Edlinger
2014 11:42:29 +0200 On Fri, 26 Sep 2014 12:48:44, Jeff Law wrote: On 09/26/14 06:21, Bernd Edlinger wrote: Hi, this patch fixes PR58893, which is an access to uninitialized memory, which may or may not crash in linemap_resolve_location, or just print error messages

RE: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory

2014-09-30 Thread Bernd Edlinger
Hi Jeff, On Mon, 29 Sep 2014 22:40:58, Jeff Law wrote: On 09/27/14 03:53, Bernd Edlinger wrote: Comment before this change. Someone not familiar with this code is going to have no idea why these two lines exist. Ok, I added a comment now, do you like it? Yes. Please try to include

[PATCH] Fix performance break-down in gcc.c-torture/unsorted/dump-noaddr.c

2014-10-01 Thread Bernd Edlinger
Hi Jeff, as you know, this test case takes too long to complete if the test suite is run with this command line: MALLOC_PERTURB_=237 make -k check The reason was found in libcpp/charset.c, where a reallocation is done one byte at a time. It seems to be in the macro expansion of this

[PATCH] Fix PR ipa/61190, 2nd edition‏

2014-10-07 Thread Bernd Edlinger
-10-07 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/61190 * cgraph.h (symtab_node::call_for_symbol_and_aliases): Fix comment. (cgraph_node::call_for_symbol_and_aliases): Likewise. (cgraph_node::call_for_symbol_thunks_and_aliases_1): New function

[PING] [PATCH] Fix PR ipa/61190, 2nd edition‏

2014-10-14 Thread Bernd Edlinger
Ping... see: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00536.html Hi Honza, as you know, we have a wrong code bug, when a pure or const method is called via a virtual thunk. I had some more Ideas, how to fix that, but all of them had some serious draw-backs, so I leave the details

[PATCH, FORTRAN] Fix PR fortran/60191

2014-03-31 Thread Bernd Edlinger
and uses r0 for the result. Boot-strapped and Regression-tested on arm-linux-gnueabihf and x86_64-linux-gnu. OK for trunk? Thanks Bernd.2014-03-31 Bernd Edlinger bernd.edlin...@hotmail.de PR fortran/60191 * fortran/trans-types.c

[PATCH, FORTRAN]

2014-04-08 Thread Bernd Edlinger
, and this can still go into 4.9.0. Boot-Strapped without any regressions on x86_64-unknown-linux-gnu. Ok for trunk? Thanks Bernd. gcc: 2014-04-08 Bernd Edlinger bernd.edlin...@hotmail.de * fortran/class.c (gfc_build_class_symbol): Append _t

FW: [PATCH, FORTRAN] Class Name Clash

2014-04-08 Thread Bernd Edlinger
unique again. I hope it is not too late, and this can still go into 4.9.0. Boot-Strapped without any regressions on x86_64-unknown-linux-gnu. Ok for trunk? Thanks Bernd. gcc: 2014-04-08 Bernd Edlinger bernd.edlin...@hotmail.de * fortran

RE: [PATCH v7?] PR middle-end/60281

2014-04-08 Thread Bernd Edlinger
Lin, are you still working on this? Thanks Bernd.

RE: [PATCH v7?] PR middle-end/60281

2014-04-09 Thread Bernd Edlinger
Hi Lin, thanks for clarifying this. If you say you can't sign the FSF copyright assignment, we can't use your patch, I'm afraid. Well, I was curious how to proceed, because these unaligned stm instructions are also a problem under linux. The test cases don't fail, because the exception handler

RE: [PATCH v7?] PR middle-end/60281

2014-04-09 Thread Bernd Edlinger
Hi Lin, Seem we are not talking the same problem.You should first make sure what has been going wrong first. Maybe I misunderstood your point. And I will sign it. -- Regards lin zuojian Ok, then please do it. Once you have signed it, and got the approval by a global GCC reviewer, I

RE: [PATCH, FORTRAN] Class Name Clash

2014-04-10 Thread Bernd Edlinger
Hi Tobias, On Thu, 10 Apr 2014 10:50:24, Tobias Burnus wrote: Bernd Edlinger wrote: this patch fixes a recently discovered name-clash in gfc_build_class_symbol. Fortunately it is quite easy to fix: just make sure that the class names of target classes end with _t, and target array classes

RE: [PATCH, FORTRAN] Class Name Clash

2014-04-10 Thread Bernd Edlinger
Hi, On Thu, 10 Apr 2014 17:15:16, Tobias Burnus wrote: Hi Bernd, On Thu, Apr 10, 2014 at 11:54:52AM +0200, Tobias Burnus wrote: No re-reading the orginal patch, I think it is okay. Thanks! http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00376.html Thanks for the commit. However, can you

[PATCH, FORTRAN] Fix PR fortran/60718

2014-04-11 Thread Bernd Edlinger
Bernd. 2014-04-11 Bernd Edlinger bernd.edlin...@hotmail.de PR fortran/60718 * trans-expr.c (gfc_conv_procedure_call): Fix a strict aliasing violation when passing a class object to a formal parameter which has the target

Re: [PATCH] Don't dump bb details when removing a block

2014-04-11 Thread Bernd Edlinger
Hi Teresa, @@ -1947,7 +1947,7 @@ remove_bb (basic_block bb) fprintf (dump_file, Removing basic block %d\n, bb-index); if (dump_flags TDF_DETAILS) { - dump_bb (dump_file, bb, 0, dump_flags); + dump_bb (dump_file, bb, 0, dump_flags ~TDF_DETAILS);

RE: [PATCH, FORTRAN] Fix PR fortran/60718

2014-04-11 Thread Bernd Edlinger
Hi Tobias, On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: Hi Bernd, Bernd Edlinger wrote: It was caused by a strict aliasing violation, when passing a value of the type class(x),pointer to a formal procedure parameter of the type class(x),target. I assume a VIEW_CONVERT_EXPR

RE: [PATCH, FORTRAN] Fix PR fortran/60718

2014-04-15 Thread Bernd Edlinger
Hi Tobias, On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote: Hi Tobias, On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: Hmm, I was hoping somehow that only that test case is broken, and needs to be fixed. The target

RE: [PATCH v7?] PR middle-end/60281

2014-04-17 Thread Bernd Edlinger
Hi Lin, On Thu, 17 Apr 2014 22:29:14, Lin Zuojian wrote: Hi Bernd, I have my copyright mark signed and the process has completed. Now I am going to answer two more questions before my patch can be commited right? Did you copy any files or text written by someone else in these changes?”

RE: [PATCH v8] PR middle-end/60281

2014-04-18 Thread Bernd Edlinger
Hi Jakub, I can take that task over and will boot-strap with all languages and run the test suite on my armv7-linux-gnueabihf system. But that will take until next week as it is currently occupied with other tests. Can you please review Lin's latest patch and give your OK for check-in on trunk

RE: [PATCH] Remove keep_aligning from get_inner_reference

2014-04-22 Thread Bernd Edlinger
should IMHO go. Richard. -- Eric Botcazou 2014-04-16 Bernd Edlinger bernd.edlin...@hotmail.de Remove parameter keep_aligning from get_inner_reference. * tree.h (get_inner_reference): Adjust header. * expr.c (get_inner_reference

RE: [PATCH] Remove keep_aligning from get_inner_reference

2014-04-22 Thread Bernd Edlinger
Hi Eric, On Tue, 22 Apr 2014 10:09:28, Eric Botcazou wrote: I still have that already-approved patch, updated to current trunk. I've successfully boot-strapped it on armv7-linux-gnueabihf with all languages enabled, including Ada. The test suite runs cleanly without any drop-outs. Thanks

[PATCH] Work around for current Cygwin-32 Build problems

2014-04-30 Thread Bernd Edlinger
for trunk and 4.9 branch? Thanks Bernd. 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de Work around for current cygwin32 build problems (Bug gas/16858). * config/i386/cygming-crtbegin.c (__register_frame_info

RE: [PATCH] Work around for current Cygwin-32 Build problems

2014-04-30 Thread Bernd Edlinger
Hi Rainer, On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: Bernd Edlinger bernd.edlin...@hotmail.de writes: 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de Work around for current cygwin32 build problems (Bug gas/16858). * config/i386/cygming-crtbegin.c (__register_frame_info

RE: [PATCH] Work around for current Cygwin-32 Build problems

2014-04-30 Thread Bernd Edlinger
Opps... this time with the attachment. Hi Rainer, On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: Bernd Edlinger bernd.edlin...@hotmail.de writes: 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de Work around for current cygwin32 build problems (Bug gas/16858). * config/i386

[PING] [PATCH, FORTRAN] Fix PR fortran/60718

2014-04-30 Thread Bernd Edlinger
Ping... Date: Tue, 15 Apr 2014 13:49:37 +0200 Hi Tobias, On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote: Hi Tobias, On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: Hmm, I was hoping somehow that only that test case

[PATCH, ADA] Fix current build problems under cygwin

2014-05-10 Thread Bernd Edlinger
it is only defined when windows.h is included. Boot-strapped under Cygwin32 and Cygwin64. OK for trunk and 4.9.1 branch? Thanks Bernd. 2014-05-10 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin build problems. * seh_init.c

[PATCH] Enable Java on Cygwin-64

2014-05-11 Thread Bernd Edlinger
on Cygwin-32 and Cygwin-64. OK for trunk and 4.9.1? Thanks Bernd. boehm-gc/ChangeLog: 2014-05-11 Bernd Edlinger bernd.edlin...@hotmail.de Fix current cygwin-64 build problems. * include/gc_config_macros.h (GC_PTHREADS): Use __CYGWIN__ instead

RE: [PATCH] Remove keep_aligning from get_inner_reference

2014-05-14 Thread Bernd Edlinger
Hi Eric, On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote: So does this remove the last concern around Bernd's patch? And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used by obj-c/c++ as well, but I can't find such use) Probably but, as previously indicated, I need to do some

RE: aarch64 build broken

2014-05-26 Thread Bernd Edlinger
Hi Jan, looks good.  Thanks! Bernd On Mon, 26 May 2014 21:07:28 +0200, Jan Hubicka wrote: From: hubi...@ucw.cz To: bernd.edlin...@hotmail.de CC: hubi...@ucw.cz; gcc-patches@gcc.gnu.org Subject: Re: aarch64 build broken Hi Jan, r210901 | hubicka | 2014-05-25 00:00:14 +0200 (So, 25.

[PATCH] Fix an AARCH64/ARM performance regression

2014-05-27 Thread Bernd Edlinger
if this patch should also go into the 4.9 branch, after a while of course. What do you think? Thanks Bernd. patch-expr.diff Description: Binary data 2014-05-27 Bernd Edlinger bernd.edlin...@hotmail.de * expr.c (expand_assignment): Fold

RE: [PATCH] Fix an AARCH64/ARM performance regression

2014-05-27 Thread Bernd Edlinger
Hi, On Tue, 27 May 2014 11:06:21, Richard Biener wrote: But the coment previously read /* A constant address in TO_RTX can have VOIDmode, we must not try to call force_reg for that case. Avoid that case. */ and you are removing that check. So I guess you want to retain GET_MODE (XEXP

RE: [PATCH, V2] Fix an AARCH64/ARM performance regression

2014-05-28 Thread Bernd Edlinger
exactly the same logic. Boot-strapped regression-tested in x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2014-05-27 Bernd Edlinger bernd.edlin...@hotmail.de * expr.c (expand_assignment): Fold the bitpos in the to_rtx if sufficiently aligned

Build problems on arm-linux-gnueabihf

2014-05-28 Thread Bernd Edlinger
Honza, I try to build this configuration: ../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran,ada --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard but make fails: libtool:

RE: Build problems on arm-linux-gnueabihf

2014-05-28 Thread Bernd Edlinger
Hi, On Wed, 28 May 2014 22:36:17, Jan Hubicka wrote: On the other hand, the alias created ought to inherit properties form its target, so yes, we probably want to copy flags that matters, including DECL_THREAD_LOCAL_P. We however should not copy DECL_INITIAL - we never have constructors for

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

2014-05-30 Thread Bernd Edlinger
Hi Kai, this patch also mis-compiles binuitls-2.24 on x86_64. In the function walk_wild_consider_section (ld/ldlang.c) a tail-call gets miscompiled: The stack frame is cleaned up, but now the jump target is invalid.    0x0040c801 +193:    add    $0x28,%rsp    0x0040c805 +197:   

[PATCH] Fix PR ipa/61190

2014-06-02 Thread Bernd Edlinger
-Tested on x86_64-linux-gnu. Ok for trunk? Thanks Bernd. 2014-06-02 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/61190 * cgraphunit.c (expand_thunk): Don't try to output the thunk for a virtual base class via

RE: [PATCH] Fix PR ipa/61190

2014-06-02 Thread Bernd Edlinger
Hi, On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote: On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, the test case g++.old-deja/g++.mike/p4736b.C is mis-compiled with with all optimization levels, except -O0 and -Og. This probably started with gcc

[PING**2] [PATCH, FORTRAN] Fix PR fortran/60718

2014-06-02 Thread Bernd Edlinger
Burnus wrote: Hi Tobias, On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote: On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote: Hmm, I was hoping somehow that only that test case is broken, and needs to be fixed. The target attribute is somehow simple, it implies intent

[PATCH] PR rtl-optimization/61047

2014-06-11 Thread Bernd Edlinger
Hi, this patch fixes PR 61047, where rtx_addr_can_trap_p_1 incorrectly assumes, that all SP-relative offsets can be safely read witout causing any traps. And therefore such references are safe to be moved out of an if-block. This patch tries to get safe lower and upper bounds where accesses are

RE: [PATCH] PR rtl-optimization/61047

2014-06-12 Thread Bernd Edlinger
On  Thu, 12 Jun 2014 10:36:25, Eric Botcazou wrote: Btw, I wonder if we can simply mark the MEMs generated from spill code with MEM_NOTRAP_P so we can remove the special casing of frame-pointer-based addresses from add while properly initializing MEM_NOTRAP_p from rtx_addr_can_trap_p? Spill

RE: [PATCH] PR rtl-optimization/61047

2014-06-12 Thread Bernd Edlinger
On Thu, 12 Jun 2014 10:50:29, Eric Botcazou wrote: Btw I am not sure at all, why argp-references can never be dangerous? For instance in a struct with an array inside, passed as function argument? IMO there cannot be any definitive solution to this issue until after we move all the affected

RE: [PATCH] PR rtl-optimization/61047

2014-06-13 Thread Bernd Edlinger
Hi, On Thu, 12 Jun 2014 12:49:13, Richard Biener wrote: On Thu, Jun 12, 2014 at 10:36 AM, Eric Botcazou ebotca...@adacore.com wrote: Btw, I wonder if we can simply mark the MEMs generated from spill code with MEM_NOTRAP_P so we can remove the special casing of frame-pointer-based addresses

[Ada] PR ada/61505

2014-06-14 Thread Bernd Edlinger
in paragraph @strong{53} I am not sure how to handle that without paragraph numbers, maybe like this: See documentation in the sources of the run time mentioned in the previous paragraph. 2014-06-14 Bernd Edlinger bernd.edlin...@hotmail.de PR ada/61505 * gnat_rm.texi: Fix errors

RE: [PATCH] Fix PR ipa/61190

2014-06-16 Thread Bernd Edlinger
Hi Honza, On Mon, 2 Jun 2014 18:12:10, Jan Hubicka wrote: Hi, On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote: On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, the test case g++.old-deja/g++.mike/p4736b.C is mis-compiled with with all optimization

Re: fix math wrt volatile-bitfields vs C++ model

2014-06-17 Thread Bernd Edlinger
Hi, On Tue, 17 Jun 2014 10:08:33, Richard Biener wrote: On Tue, Jun 17, 2014 at 4:08 AM, DJ Delorie d...@redhat.com wrote: Looks ok to me, but can you add a testcase please? I have a testcase, but if -flto the testcase doesn't include *any* definition of the test function, just all the LTO

RE: [PATCH, rs6000] Fix PR61542 - V4SF vector extract for little endian

2014-06-18 Thread Bernd Edlinger
Hi, On Wed, 18 Jun 2014 09:56:15, David Edelsohn wrote: On Tue, Jun 17, 2014 at 6:44 PM, BIll Schmidt wschm...@linux.vnet.ibm.com wrote: Hi, As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542, a new test case (gcc.dg/vect/vect-nop-move.c) was added in 4.9. This exposes a

RE: Still fails with strict-volatile-bitfields

2014-02-03 Thread Bernd Edlinger
about a configure option to set default? Thanks, Joey On Fri, Jan 10, 2014 at 10:20 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote: On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: On, Fri, 10 Jan 2014

RE: [PING**2] Another build!=host fix

2014-02-04 Thread Bernd Edlinger
Ping... this is still open, in short, the configuration ../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-cross --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran,ada --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16

[PATCH] Fix for PR60080

2014-02-07 Thread Bernd Edlinger
.2014-02-06 Bernd Edlinger bernd.edlin...@hotmail.de PR middle-end/60080 * cfgexpand.c (expand_asm_operands): Attach source location to ASM_INPUT rtx objects. * print-rtl.c (print_rtx): Check for UNKNOWN_LOCATION. patch-pr60080.diff Description: Binary

[PATCH] Fix c-c++-common/ubsan/overflow-negate-2.c

2014-02-14 Thread Bernd Edlinger
Hi, this test case fails on ARM, because this target has by default unsigned char type. Attached please find my proposed (almost obvious) fix for this, by using signed char, instead of char alone. Boot-Strapped and tested on X86_64 and ARM. Thanks Bernd.

[PATCH] Fix fortran/pr60236

2014-02-23 Thread Bernd Edlinger
Hi, the test case gfortran.dg/vect/pr32380.f was found to fail on armv7l-unknown-linux-gnueabihf. The reason for this is that one out of 6 loops does not get vectorized, because this target does not support a vectorization of sqrtf. The same test case is known to fail on powerpc-apple-darwin9

RE: [PATCH v4] PR middle-end/60281

2014-02-27 Thread Bernd Edlinger
the required mode. Regards Bernd Edlinger.

RE: [PATCH v4] PR middle-end/60281

2014-03-01 Thread Bernd Edlinger
intent to make it right.Making it best is next task. -- Regards lin zuojian. 于 2014年02月28日 15:47, Bernd Edlinger 写道: Hi, I see the problem too. But I think it is not necessary to change the stack alignment to solve the problem. It appears to me that the code in asan_emit_stack_protection

[PING] [PATCH] Fix fortran/pr60236

2014-03-02 Thread Bernd Edlinger
Ping. Subject: [PATCH] Fix fortran/pr60236 Date: Sun, 23 Feb 2014 14:50:46 +0100 Hi, the test case gfortran.dg/vect/pr32380.f was found to fail on armv7l-unknown-linux-gnueabihf. The reason for this is that one out of 6 loops does not get vectorized, because this target does not

RE: [PING**2] [PATCH] Fix PR ipa/61190, 2nd edition‏

2014-10-27 Thread Bernd Edlinger
Ping again... Thanks. From: bernd.edlin...@hotmail.de To: hubi...@ucw.cz CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com Subject: [PING] [PATCH] Fix PR ipa/61190, 2nd edition‏ Date: Tue, 14 Oct 2014 11:40:56 +0200 Ping... see:

[PATCH] PR58143/58227 wrong code at -O3

2013-08-28 Thread Bernd Edlinger
-fno-strict-overflow. The test case looks pretty constructed anyway. The patch was boot-strapped and regression tested on i686-pc-linux-gnu and X86_64-linux-gnu OK for trunk? Regards Bernd Edlinger2013-08-28 Bernd Edlinger bernd.edlin...@hotmail.de

RE: [PATCH] PR58143/58227 wrong code at -O3

2013-08-30 Thread Bernd Edlinger
On Thu, 29 Aug 2013 11:54:22, Richard Biener wrote: On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: The lim pass (aka loop invariant motion) can move conditional expressions with possible undefined behavior out of the if statement inside a loop which may

[PATCH, committed] MAINTAINERS (Write After Approval): Add myself.

2013-08-30 Thread Bernd Edlinger
Index: ChangeLog === --- ChangeLog (revision 202117) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2013-08-30 Bernd Edlinger bernd.edlin...@hotmail.de + + * MAINTAINERS (Write After Approval): Add myself. + 2013-08-27

Re: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

2013-09-01 Thread Bernd Edlinger
On Fri, 30 Aug 2013 11:47:21, Richard Biener wrote: On Tue, Jul 2, 2013 at 7:33 PM, DJ Delorie d...@redhat.com wrote: The choice appears to be to continue to have broken volatile bitfields on ARM with no way for users to make them conform to the ABI, or to change things so that they conform

RE: [PATCH] Fix PR tree-optimization/58137

2013-09-02 Thread Bernd Edlinger
On Fri, 30 Aug 2013 12:34:51 Richard Biener wrote: On Tue, Aug 20, 2013 at 1:01 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: This patch fixes a bug in the vectorized pointer arithmetic in the forwprop optimization pass. Although it seems to be impossible to create a vector of pointers

[PATCH] Portable Volatility Warning

2013-09-02 Thread Bernd Edlinger
platform. Regards Bernd Edlinger2013-09-03 Bernd Edlinger bernd.edlin...@hotmail.de Implement -Wportable-volatility warning to warn about code which accesses volatile structure members for which different ABI specifications exist

RE: [ping**n] reimplement -fstrict-volatile-bitfields, v3

2013-09-02 Thread Bernd Edlinger
On Mon, 2 Sep 2013 12:56:22 Sandra Loosemore wrote: On 09/02/2013 03:10 AM, Richard Biener wrote: Can someone, in a new thread, ping the patches that are still in flight? ISTR having approved bits of some patches before my leave. Here's the current state of the patch set I put together. I've

RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

2013-09-03 Thread Bernd Edlinger
On Tue, 3 Sep 2013 10:30:22, Richard Biener wrote: On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 2 Sep 2013, Richard Earnshaw wrote: On 01/09/13 14:10, Bernd Edlinger wrote: IMHO the AAPCS forbids packed structures. Therefore we need not interfere

RE: [PATCH] Portable Volatility Warning

2013-09-03 Thread Bernd Edlinger
On Tue, 3 Sep 2013 10:53:10, Richard Biener wrote: On Tue, Sep 3, 2013 at 2:05 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: This is a follow-up patch for Sandra Loosemore's patch in this thread: reimplement -fstrict-volatile-bitfields, v3. It was already posted a few weeks ago

RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

2013-09-04 Thread Bernd Edlinger
On Tue, 3 Sep 2013 21:20:04, Joseph S. Myers wrote: On Tue, 3 Sep 2013, Bernd Edlinger wrote: The trouble is that AAPCS semantics are incompatible with the default GNU semantics for non-packed structures as well - AAPCS strict-volatile-bitfields is only compatible with --param allow-store

RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

2013-09-04 Thread Bernd Edlinger
On Wed, 4 Sep 2013 09:29:02, DJ Delorie wrote: I fully agree with you, the current default state of -fstrict-volatile-bitfields should be disabled for all targets. Please don't do that until gcc produces code that does the same things. Most of my targets rely on gcc not doing the old

RE: [PATCH] PR58143/58227 wrong code at -O3

2013-09-04 Thread Bernd Edlinger
On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote: On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Now I think this is good opportunity for a simple heuristic: If a statement is at loop level 1 we can move it out of the loop, regardless of the fact

RE: [PATCH] Fix PR tree-optimization/58137

2013-09-05 Thread Bernd Edlinger
and regression tested on x86_64-unknown-linux-gnu. OK for trunk? Bernd.2013-09-05 Bernd Edlinger bernd.edlin...@hotmail.de PR tree-optimization/58137 Use POINTER_PLUS_EXPR for vector of pointer additions. * tree-cfg.c

RE: [PATCH] Fix PR tree-optimization/58137

2013-09-05 Thread Bernd Edlinger
On Thu, 5 Sep 2013 12:25:08, Richard Biener wrote: On Thu, Sep 5, 2013 at 11:43 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: this would cause an ICE in test case 2629-1.c... Well, that's easily fixable. So removing the pointer of vectors is not an option. Let me nevertheless

RE: [PATCH] Portable Volatility Warning

2013-09-05 Thread Bernd Edlinger
On Wed, 4 Sep 2013 19:48:13, Hans-Peter Nilsson wrote: On Tue, 3 Sep 2013, Richard Biener wrote: I think the warning can be completely implemented inside struct-layout.c for example in finish_bitfield_representative (if you pass that the first field in the group, too). Of course that is at

[PATCH, PR 57748] Check for out of bounds access

2013-09-06 Thread Bernd Edlinger
and the 4.8 / 4.7 branch? Regards Bernd Edlinger2013-09-06 Bernd Edlinger bernd.edlin...@hotmail.de PR middle-end/57748 * expr.c (expand_assignment): Check for out of bounds access to structures. testsuite: * gcc.dg/torture/pr57748-1

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-06 Thread Bernd Edlinger
Just for completeness, these were the test examples on this private communication: On Fri, 6 Sep 2013 11:19:18, Richard Biener wrote: On Fri, Sep 6, 2013 at 10:35 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Richard, But the movmisalign path skips all this code and with the current

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-06 Thread Bernd Edlinger
: 2013-08-08 Bernd Edlinger bernd.edlin...@hotmail.de PR target/58065 * config/arm/arm.h (MALLOC_ABI_ALIGNMENT): Define. maybe we should first backport this one. Yesterday someone did that on the linaro branch, but maybe /branches/gcc-4_8-branch should be updated as well? Bernd.

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-11 Thread Bernd Edlinger
On Tue, 10 Sep 2013 21:32:29, Martin Jambor wrote: Hi, On Fri, Sep 06, 2013 at 11:19:18AM +0200, Richard Biener wrote: On Fri, Sep 6, 2013 at 10:35 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Richard, But the movmisalign path skips all this code and with the current code thinks

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-12 Thread Bernd Edlinger
On Wed, 11 Sep 2013 15:43:53, Richard Biener wrote: On Wed, Sep 11, 2013 at 3:41 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: On Tue, 10 Sep 2013 21:32:29, Martin Jambor wrote: The misalignp path was added by you during the 4.7 development to fix PR 50444 which was indeed about

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-13 Thread Bernd Edlinger
While it is straight forward to remove the movmisalign path in 4.9 and 4.8, this is not so simple in the 4.7 branch. The reason is that 4.7 uses to_rtx = expand_normal (tem); while 4.8 and 4.9 use to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE); which does almost the same, but

RE: [PATCH, PR 57748] Check for out of bounds access

2013-09-15 Thread Bernd Edlinger
, but there were none. OK for trunk? Regards Bernd.2013-09-15 Bernd Edlinger bernd.edlin...@hotmail.de PR middle-end/57748 * expr.c (expand_assignment): Remove misalignp code path. Check for bitregion in offset arithmetic

  1   2   3   4   5   6   7   8   9   10   >