On Fri, Jul 10, 2015 at 02:06:26PM -0600, Jeff Law wrote:
> On 07/10/2015 07:25 AM, Ondřej Bílka wrote:
> >On Fri, Jul 10, 2015 at 12:43:48PM +0200, Jakub Jelinek wrote:
> >>On Fri, Jul 10, 2015 at 11:37:18AM +0200, Uros Bizjak wrote:
> >>>Have you tried new SSE4.2 im
On Fri, Jul 10, 2015 at 12:43:48PM +0200, Jakub Jelinek wrote:
> On Fri, Jul 10, 2015 at 11:37:18AM +0200, Uros Bizjak wrote:
> > Have you tried new SSE4.2 implementation (the one with asm flags) with
> > unrolled loop?
>
> Also, the SSE4.2 implementation looks shorter, so more I-cache friendly,
>
Hi,
As I wrote at
[PATCH, libcpp]: Use asm flag outputs in search_line_sse42 main loop
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg113610.html
I wont repeat myself with reasons summary is that current sse4.2 code is
reduntant as it has same performance as sse2 one.
This improves s
On Thu, Jul 09, 2015 at 03:46:08PM +0200, Richard Biener wrote:
> On Thu, 9 Jul 2015, Bernhard Reutner-Fischer wrote:
>
> > gcc/ChangeLog
> >
> > 2015-07-09 Bernhard Reutner-Fischer
> >
> > * builtins.c (fold_builtin_tolower, fold_builtin_toupper): New
> > static functions.
> > (f
On Mon, Jun 29, 2015 at 09:07:22PM +0200, Uros Bizjak wrote:
> Hello!
>
> Attached patch introduces asm flag outputs in seach_line_sse42 main
> loop to handle carry flag value from pcmpestri insn. Slightly improved
> old code that uses asm loop compiles to:
>
Using sse4.2 here is bit dubios as pcm
On Wed, Mar 05, 2014 at 08:05:25AM -0800, Ian Lance Taylor wrote:
> On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
> wrote:
> > On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
> >> The GNU glibc qsort function will call malloc in some cases. That makes
> >> it unsuitable for libbacktrace
On Sat, Feb 15, 2014 at 10:50:02AM +0100, Richard Biener wrote:
> On Sat, Feb 15, 2014 at 10:45 AM, Prathamesh Kulkarni
> wrote:
> > On Sat, Feb 15, 2014 at 2:28 PM, Jakub Jelinek wrote:
> >> On Sat, Feb 15, 2014 at 02:23:24PM +0530, Prathamesh Kulkarni wrote:
> >>> This patch folds strchr (e, 0)
On Fri, Dec 06, 2013 at 04:16:04PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> > Currently this code with sanitize=address gets expanded
> >
> > int foo(char *x, char *y, int i)
> > {
> > x[i] = y[i];
On Fri, Dec 06, 2013 at 01:34:43PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> > On second though besides of decreasing of code size there is no reason
> > to complicate compilation for these features. A more flexible way is add
On Fri, Dec 06, 2013 at 01:09:29PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> > Hi all,
> >
> > GCC version of Asan currently lacks options for detailed control
> > over code instrumentation. These are not usually necessary but for
> > embedded sys
On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control
> over code instrumentation. These are not usually necessary but for
> embedded systems with scarce system resources Asan memory overhead
> of 2x-3x may often
On Tue, Nov 12, 2013 at 05:01:31PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Ondřej Bílka wrote:
>
> >On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote:
> >>On Tue, 12 Nov 2013, Ondřej Bílka wrote:
> >>
> >>>>I am trying to get
On Tue, Nov 12, 2013 at 12:55:17AM +0100, Marc Glisse wrote:
> On Mon, 11 Nov 2013, Richard Biener wrote:
>
> >On Sun, Nov 10, 2013 at 4:27 PM, Marc Glisse wrote:
> >>Hello,
> >>
> >>I am posting this patch to get some feedback on the approach. The goal is to
> >>replace malloc+free with a stack
On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Ondřej Bílka wrote:
>
> >>I am trying to get something to actually work and be accepted in
> >>gcc. That may mean being conservative.
> >
> >That also may mean that you will cov
On Tue, Nov 12, 2013 at 01:16:14AM +0100, Marc Glisse wrote:
> On Mon, 11 Nov 2013, Ondřej Bílka wrote:
>
> >On Sun, Nov 10, 2013 at 04:27:00PM +0100, Marc Glisse wrote:
> >>Hello,
> >>
> >>I am posting this patch to get some feedback on the approach. The
&g
On Mon, Nov 11, 2013 at 11:19:05AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 11:08:14AM +0100, Ondřej Bílka wrote:
> > On Sun, Nov 10, 2013 at 04:27:00PM +0100, Marc Glisse wrote:
> > > I am posting this patch to get some feedback on the approach. The
> > >
On Sun, Nov 10, 2013 at 04:27:00PM +0100, Marc Glisse wrote:
> Hello,
>
> I am posting this patch to get some feedback on the approach. The
> goal is to replace malloc+free with a stack allocation (a decl
> actually) when the size is a small constant.
>
Why constraint yourself to small sizes. Stac
On Wed, Oct 30, 2013 at 11:05:58AM +0100, Jakub Jelinek wrote:
> On Wed, Oct 30, 2013 at 11:00:13AM +0100, Jakub Jelinek wrote:
> > But the above is 16 byte unaligned load. Furthermore, GCC supports
> > -mavx256-split-unaligned-load and can emit 32 byte loads either as an
> > unaligned 32 byte loa
On Wed, Oct 30, 2013 at 10:47:13AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Yesterday I've noticed that for AVX which allows unaligned operands in
> AVX arithmetics instructions we still don't combine unaligned loads with the
> AVX arithmetics instructions. So say for -O2 -mavx -ftree-vectorize
> vo
On Sun, Oct 20, 2013 at 06:55:40PM +0600, Roman Gareev wrote:
> Dear gcc contributors,
>
> Recently I came across the list of "ideas for speeding up GCC"
> (http://gcc.gnu.org/wiki/Speedup_areas). Among others, there was
> suggested to replace identifier hash table with other data structure.
>
>
On Mon, Jul 29, 2013 at 12:10:42PM +0100, Marcus Shawcroft wrote:
> On 28/07/13 23:03, Maxim Kuvyrkov wrote:
> >While verifying license compliance for GCC and its libraries I noticed that
> >several libgcc files that end up in the final library are licensed under
> >GPL-3.0+ instead of GPL-3.0-wi
On Tue, Jul 23, 2013 at 12:26:23PM +0100, Jonathan Wakely wrote:
> I agree with all Paolo's comments.
>
> Also libstdc++-v3/doc/html/ext/lwg-active.html is imported from
> elsewhre so it's pointless fixing it, the upstream version comes from
> https://github.com/cplusplus/LWG
>
ok, I have one red
x 9cc34c5..517f17a 100644
--- a/gcc/java/ChangeLog
+++ b/gcc/java/ChangeLog
@@ -1,3 +1,7 @@
+2013-07-23 Ondřej Bílka
+
+ * class.c: Fix typos in java.
+
2013-06-05 Jan Hubicka
* class.c (emit_register_classes_in_jcr_section): Use DECL_PRESERVE_P
diff --git a/gcc/java/class.c b/gcc/ja
/dev/ptym/clone"). Indeed it seems that there are
^ ^
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
index 4e0b0a8..f1904b1 100644
--- a/gcc/ada/ChangeLog
+++ b/gcc/ada/ChangeLog
@@ -1,3 +1,11 @@
+2013-07-23 Ondřej Bílka
+
+ * gnat_rm.te
^ ^
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c531d03..74ec79e 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,11 @@
+2013-07-23 Ondřej Bílka
+
+ * decl.c: Fix typos in fortran.
+ * interface.c: Likewise.
+ * symbol.c
On Sun, Jul 21, 2013 at 04:44:40PM +0200, Marc Glisse wrote:
> On Sun, 21 Jul 2013, Ondřej Bílka wrote:
>
> >Then I ran script/stylepp_fix_spell which produced following 300kb patch:
> >
> >http://kam.mff.cuni.cz/~ondra/0001-Fix-common-typos.patch
>
> There are
On Sun, Jul 21, 2013 at 09:09:37AM -0700, Mike Stump wrote:
> On Jul 21, 2013, at 7:32 AM, Ondřej Bílka wrote:
> > + * c-c++-common/raw-string-13.c: Likewise.
> >
> > + * c-c++-c
t a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
> index d2c80b3..a6c7d5f 100644
> --- a/libsanitizer/ChangeLog
> +++ b/libsanitizer/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-07-21 OndÅej BÃlka
> +
> + * tsan/tsan_interface_atomic.cc: Fix typos.
>
> I don't th
Hi,
This is series of typo fixing patches. They are generated with stylepp
https://github.com/neleai/stylepp
which makes patch generation very effective.
This series should be applied in sequence to avoid reviewing duplicates.
Now I exclude those directories that are upstream, see file
https://g
On Wed, Jul 10, 2013 at 04:01:54PM +0100, Jonathan Wakely wrote:
> On 10 July 2013 15:47, David Malcolm wrote:
> > On Wed, 2013-07-10 at 16:00 +0200, Ondřej Bílka wrote:
> >
> >> Dead link: http://fedora.linux.duke.edu/fc1_x86_64
> >
> > FWIW, this link occu
On Mon, Jul 08, 2013 at 09:42:14PM +0200, Oleg Endo wrote:
> On Mon, 2013-07-08 at 16:12 +0200, Ondřej Bílka wrote:
> > On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote:
> > > On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote:
> > >
> > > - h
On Sun, Jul 07, 2013 at 09:57:05PM +0200, Oleg Endo wrote:
> On Sun, 2013-07-07 at 19:54 +0200, Georg-Johann Lay wrote:
> > Ondrej Bilka schrieb:
> >
> > > http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
> >
I fixed most comments, put it here so you can diff these two files.
http://kam.mff.cuni.c
On Sun, Jul 07, 2013 at 07:54:34PM +0200, Georg-Johann Lay wrote:
> Ondrej Bilka schrieb:
>
> >http://kam.mff.cuni.cz/~ondra/gcc_misspell.patch
>
> This is wrong:
>
> @@ -10834,7 +10834,7 @@ avr_convert_to_type (tree type, tree expr)
> XOP[2] # Bytes to copy
>
> Return TRUE if the exp
On Sun, Jul 07, 2013 at 04:21:15PM +0200, Ondřej Bílka wrote:
> On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote:
> > I decided to grep for all the misspelled words beginning with A from
> > your list and fix the ones that were real errors. That took me an hour
>
On Sat, Jul 06, 2013 at 01:14:38PM +0100, Jonathan Wakely wrote:
> I decided to grep for all the misspelled words beginning with A from
> your list and fix the ones that were real errors. That took me an hour
> to produce this patch. It doesn't include changes to java or fortran,
> as I don't have
Ping
On Tue, Jun 18, 2013 at 02:56:52PM +0800, Chung-Ju Wu wrote:
> 2013/6/16 Ondřej Bílka :
> > On Sat, Jun 15, 2013 at 05:13:31PM +0800, Chung-Ju Wu wrote:
> >> 2013/6/14 Joseph S. Myers :
> >> > On Thu, 13 Jun 2013, Richard Biener wrote:
> >> >
> >
On Sun, Jun 30, 2013 at 11:06:47AM +0200, Jan Hubicka wrote:
> > On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin
> > wrote:
> > > Ping.
> > >
> > > On 20 June 2013 20:56, Michael Zolotukhin
> > > wrote:
> > >> It seems that one of the tests needed a small fix.
> > >> Attached is a corrected v
On Sat, Jun 15, 2013 at 05:13:31PM +0800, Chung-Ju Wu wrote:
> 2013/6/14 Joseph S. Myers :
> > On Thu, 13 Jun 2013, Richard Biener wrote:
> >
> >> Btw, rather than these kind of patches I'd appreciate if someone would look
> >> at a simple pre(post?)-commit hook that enforces those whitespace rules
On Wed, Jun 12, 2013 at 10:30:40PM +0200, Marc Glisse wrote:
> On Wed, 12 Jun 2013, Ondřej Bílka wrote:
>
> >I am writing a tool to fix common style issues.
> >
> >This is first part which deals with leading and trailing whitespaces.
> >I can follow this up with o
On Sat, Jun 15, 2013 at 05:13:31PM +0800, Chung-Ju Wu wrote:
> 2013/6/14 Joseph S. Myers :
> > On Thu, 13 Jun 2013, Richard Biener wrote:
> >
> >> Btw, rather than these kind of patches I'd appreciate if someone would look
> >> at a simple pre(post?)-commit hook that enforces those whitespace rules
On Thu, Jun 13, 2013 at 10:08:23AM +0200, Richard Biener wrote:
> On Wed, Jun 12, 2013 at 10:08 PM, Ondřej Bílka wrote:
> > A followup to previous patch is more general pass that changes leading
> > spaces to tabs followed by at most 8 spaces.
> >
> > http://kam.mff.cu
On Thu, Jun 13, 2013 at 09:45:23AM +0200, Marek Polacek wrote:
> On Wed, Jun 12, 2013 at 10:18:29PM +, Joseph S. Myers wrote:
> > In general I think no formatting fixes should be made to GCC testcases,
> > including removal of trailing whitespace; it's good if they cover a range
> > of coding
A followup to previous patch is more general pass that changes leading
spaces to tabs followed by at most 8 spaces.
http://kam.mff.cuni.cz/~ondra/0004-Formatted-by-leading_space.patch
Now we move to leading spaces,
If you want only to fix leading spaces followed by tab then please use
following patch
http://kam.mff.cuni.cz/~ondra/0003-Formatted-by-space_before_tab.patch
A second part of this cleanup is optional.
If you want to preserve form feeds its your decision, If you want to
remove them here is patch.
http://kam.mff.cuni.cz/~ondra/0002-Formatted-by-form_feed.patch
Hi,
I am writing a tool to fix common style issues.
This is first part which deals with leading and trailing whitespaces.
I can follow this up with other refactorings, for example rewriting
K&R definitions.
I wrote a simple programs that fixes them.
Then it suffices for me or any volunteer to r
On Wed, May 08, 2013 at 07:56:18PM +0400, Alexander Monakov wrote:
> Hello,
>
> I'd like to make libbacktrace easier to import for use in other software.
> Right now it's mostly standalone, but depends on rest of GCC in the following:
>
> 1. Build system.
> 2. Trivially depends on "filenames.h".
st 100 sizes, then
switches to my implementation.
I added memcpy_new_builtin which is now same as memcpy_gcc_builtin.
To add your implementation compile variant/builtin.c file into
variant/builtin.s file.
Then run ./benchmark.
Ondra
> Michael
>
> On 12 April 2013 12:54, Ondřej Bílka w
.
To use other builtin change in Makefile how to compile variant/builtin.c
file.
A builtin are faster by inlined function call, I did not add that as I
do not know estimate of this cost.
> Michael
>
> On 10 April 2013 22:53, Ondřej Bílka wrote:
> > On Wed, Apr 10, 2013 at 09:
ng - tuning is certainly
> possible and needed, but that's out of the scope of the patch.
>
> On 10 April 2013 21:43, Ondřej Bílka wrote:
> > On Wed, Apr 10, 2013 at 08:14:30PM +0400, Michael Zolotukhin wrote:
> >> Hi,
> >> This patch adds a new algorithm of expa
On Wed, Apr 10, 2013 at 08:14:30PM +0400, Michael Zolotukhin wrote:
> Hi,
> This patch adds a new algorithm of expanding movmem in x86 and a bit
> refactor existing implementation. This is a reincarnation of the patch
> that was sent wasn't checked couple of years ago - now I reworked it
> from scr
On Wed, Mar 27, 2013 at 10:20:59AM +0100, Tobias Burnus wrote:
> (The email below was only sent to gcc-patches@; I now also CC
> fortran@ - sorry for the full quote)
>
> Regarding the below patch: I think it does not work as-is for
> Unicode strings (UCS4, character(kind=4)), where each character
On Tue, Mar 26, 2013 at 11:53:27PM +0200, Janne Blomqvist wrote:
> On Mon, Mar 25, 2013 at 7:00 PM, Thomas Koenig wrote:
> > Hello world,
> >
> > this patch uses memcpy() directly when comparing two kind=1 strings of
> > equal and constant lengths. The test case modification depends
> > on the pr
Hi,
as I looked to compare_string I discovered that it could be
optimized. This speeds up case when strings are equal but we must check
padding where checking it byte by byte is suboptimal.
Ondra
2013-03-27 Ondřej Bílka
* libgfortran/intrinsics/string_intrinsics_inc.c
54 matches
Mail list logo
