Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Richard Guenther 
On Sun, Dec 5, 2010 at 8:56 AM, Chris Lattner  wrote:
>
> On Dec 4, 2010, at 5:22 AM, Florian Weimer wrote:
>
>> * Joe Buck:
>>
>>> It's wasted code if the multiply instruction detects the overflow.
>>> It's true that the cost is small (maybe just one extra instruction
>>> and the same number of tests, maybe one more on architectures where you
>>> have to load a large constant), but it is slightly worse code than what
>>> Chris Lattner showed.
>>
>> It's possible to improve slightly on the LLVM code by using the
>> overflow flag (at least on i386/amd64), as explained in this blog
>> post:
>>
>> 
>
> Ah, great point.  I improved the clang codegen to this:
>
> $ cat t.cc
> void *test(long count) {
>      return new int[count];
> }
> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
> -show-mc-encoding
>        .section        __TEXT,__text,regular,pure_instructions
>        .globl  __Z4testl
>        .align  4, 0x90
> __Z4testl:                              ## @_Z4testl
> ## BB#0:                                ## %entry
>        movl    $4, %ecx                ## encoding: [0xb9,0x04,0x00,0x00,0x00]
>        movq    %rdi, %rax              ## encoding: [0x48,0x89,0xf8]
>        mulq    %rcx                    ## encoding: [0x48,0xf7,0xe1]
>        movq    $-1, %rdi               ## encoding: 
> [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
>        cmovnoq %rax, %rdi              ## encoding: [0x48,0x0f,0x41,0xf8]
>        jmp     __Znam                  ## TAILCALL
>                                        ## encoding: [0xeb,A]
>                                        ##   fixup A - offset: 1, value: 
> __Znam-1, kind: FK_PCRel_1
> .subsections_via_symbols
>
> This could be further improved by inverting the cmov condition to avoid the 
> first movq, which we'll tackle as a general regalloc improvement.

I'm curious as on how you represent the overflow checking in your highlevel IL.

Richard.

> Thanks for the pointer!
>
> -Chris
>
>

build_int_cstu does not work as advertised

2010-12-05 Thread Florian Weimer 
Trunk has this:

| /* Create an INT_CST node with a CST value zero extended.  */
| 
| static inline tree
| build_int_cstu (tree type, unsigned HOST_WIDE_INT cst)
| {
|   return double_int_to_tree (type, uhwi_to_double_int (cst));
| }

But the comment is misleading because of:

| /* Constructs tree in type TYPE from with value given by CST.  Signedness
|of CST is assumed to be the same as the signedness of TYPE.  */
| 
| tree
| double_int_to_tree (tree type, double_int cst)
| {
|   /* Size types *are* sign extended.  */
|   bool sign_extended_type = (!TYPE_UNSIGNED (type)
||| (TREE_CODE (type) == INTEGER_TYPE
|&& TYPE_IS_SIZETYPE (type)));
| 
|   cst = double_int_ext (cst, TYPE_PRECISION (type), !sign_extended_type);
| 
|   return build_int_cst_wide (type, cst.low, cst.high);
| }

So for size types, build_int_cstu does not peform zero extension, but
sign extension.

If I don't want sign extension, what function should I use instead?
Should I just call build_int_cst_wide directly?

And is HOST_WIDE_INT guaraunteed to be able to hold 64 bits?  I recall
a discussion were it was said that cross-builds from hosts with narrow
HOST_WIDE_INT to 64 bit targets weren't supported.

Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Chris Lattner 

On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:

>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
>> -show-mc-encoding
>>.section__TEXT,__text,regular,pure_instructions
>>.globl  __Z4testl
>>.align  4, 0x90
>> __Z4testl:  ## @_Z4testl
>> ## BB#0:## %entry
>>movl$4, %ecx## encoding: 
>> [0xb9,0x04,0x00,0x00,0x00]
>>movq%rdi, %rax  ## encoding: [0x48,0x89,0xf8]
>>mulq%rcx## encoding: [0x48,0xf7,0xe1]
>>movq$-1, %rdi   ## encoding: 
>> [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
>>cmovnoq %rax, %rdi  ## encoding: [0x48,0x0f,0x41,0xf8]
>>jmp __Znam  ## TAILCALL
>>## encoding: [0xeb,A]
>>##   fixup A - offset: 1, value: 
>> __Znam-1, kind: FK_PCRel_1
>> .subsections_via_symbols
>> 
>> This could be further improved by inverting the cmov condition to avoid the 
>> first movq, which we'll tackle as a general regalloc improvement.
> 
> I'm curious as on how you represent the overflow checking in your highlevel 
> IL.

The (optimized) generated IR is:

$ clang t.cc -emit-llvm -S -o - -O3
...
define noalias i8* @_Z4testl(i64 %count) ssp {
entry:
  %0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
  %1 = extractvalue %0 %0, 1
  %2 = extractvalue %0 %0, 0
  %3 = select i1 %1, i64 -1, i64 %2
  %call = tail call noalias i8* @_Znam(i64 %3)
  ret i8* %call
}

More information on the overflow intrinsics is here:
http://llvm.org/docs/LangRef.html#int_overflow

-Chris

Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Chris Lattner 

On Dec 5, 2010, at 9:49 AM, Chris Lattner wrote:

> 
> On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
> 
>>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
>>> -show-mc-encoding
>>>   .section__TEXT,__text,regular,pure_instructions
>>>   .globl  __Z4testl
>>>   .align  4, 0x90
>>> __Z4testl:  ## @_Z4testl
>>> ## BB#0:## %entry
>>>   movl$4, %ecx## encoding: 
>>> [0xb9,0x04,0x00,0x00,0x00]
>>>   movq%rdi, %rax  ## encoding: [0x48,0x89,0xf8]
>>>   mulq%rcx## encoding: [0x48,0xf7,0xe1]
>>>   movq$-1, %rdi   ## encoding: 
>>> [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
>>>   cmovnoq %rax, %rdi  ## encoding: [0x48,0x0f,0x41,0xf8]
>>>   jmp __Znam  ## TAILCALL
>>>   ## encoding: [0xeb,A]
>>>   ##   fixup A - offset: 1, value: 
>>> __Znam-1, kind: FK_PCRel_1
>>> .subsections_via_symbols
>>> 
>>> This could be further improved by inverting the cmov condition to avoid the 
>>> first movq, which we'll tackle as a general regalloc improvement.
>> 
>> I'm curious as on how you represent the overflow checking in your highlevel 
>> IL.
> 
> The (optimized) generated IR is:
> 
> $ clang t.cc -emit-llvm -S -o - -O3
> ...
> define noalias i8* @_Z4testl(i64 %count) ssp {
> entry:
>  %0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
>  %1 = extractvalue %0 %0, 1
>  %2 = extractvalue %0 %0, 0
>  %3 = select i1 %1, i64 -1, i64 %2
>  %call = tail call noalias i8* @_Znam(i64 %3)
>  ret i8* %call
> }

Sorry, it's a little easier to read with expanded names and types:

define noalias i8* @_Z4testl(i64 %count) ssp {
entry:
  %A = tail call { i64, i1 } @llvm.umul.with.overflow.i64(i64 %count, i64 4)
  %B = extractvalue { i64, i1 } %A, 1
  %C = extractvalue { i64, i1 } %A, 0
  %D = select i1 %B, i64 -1, i64 %C
  %call = tail call noalias i8* @_Znam(i64 %D)
  ret i8* %call
}

-Chris

Re: PATCH: 2 stage BFD linker for LTO plugin

2010-12-05 Thread H.J. Lu 
On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu  wrote:
> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu  wrote:
>> On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu  wrote:
>>> On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu  wrote:
 On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn  
 wrote:
> On 04/12/2010 01:24, H.J. Lu wrote:
>
>> I checked in a patch to implement stage 2 linking. Everything
>> seems to work, including "gcc -static ... -lm".
>
>  Any chance you could send a complete diff?
>

 I will submit a complete diff after I fix a few corner cases.
 In the meantime, you can clone my git tree and do a "git diff".

>>>
>>> Hi,
>>>
>>> This patch implements 2 stage BFD linker for LTO plugin.
>>> It works with current LTO API on all cases I tested.
>>>
>>> Known issue:  --whole-archive will call plugin on archives with IR
>>> in stage 2 linking. But ld never calls plugin to get back object files.
>>> I will try to avoid it in a follow up patch.
>>>
>>
>> This turns out not a problem. In stage 2 linking, for --whole-archive
>> we call plugin to get symbols in the IR element of an archive and
>> it will be ignored for stage 2 linking.  It is OK since we already get
>> the trans object files back for stage 2 linking.
>>
>> BTW, the new linker passed bootstrap-lto with all default languages.
>> I am planning to include this patch in the next Linux binutils.
>>
>
> I missed the IR object in an archive:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
>
> This updated patch fixed it.  OK for trunk?
>

We shouldn't clear SEC_EXCLUDE if BFD_PLUGIN is set:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c38

This updated patch fixed it.  OK for trunk?

Thanks.


-- 
H.J.
bfd/

2010-12-05  H.J. Lu  

PR ld/12248
* bfd.c (BFD_PLUGIN): New.
(BFD_FLAGS_SAVED): Add BFD_PLUGIN.
(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.

* bfd-in2.h: Regenerated.

ld/

2010-12-05  H.J. Lu  

PR ld/12248
* ldfile.c (ldfile_try_open_bfd): Set BFD_PLUGIN for plugin. Set
stage1.

* ldlang.c (cmdline_list): New.
(cmdline_next_claimed_output): Likewise.
(cmdline_list_init): Likewise.
(cmdline_get_stage2_input_files): Likewise.
(debug_cmdline_list): Likewise.
(cmdline_list_append): Likewise.
(cmdline_set_next_claimed_output): Likewise.
(cmdline_list_insert_claimed_output): Likewise.
(new_afile): Set stage1 to FALSE;
(lang_init): Call cmdline_list_init.
(lang_gc_sections): Don't clear SEC_EXCLUDE if BFD_PLUGIN is
set.
(lang_process): Call plugin_active_plugins_p to check plugin
support.  Check cmdline_next_claimed_output before opening
stage 2 input.  Call debug_cmdline_list if trace_file_tries
is set.  Call cmdline_get_stage2_input_files to get stage 2
input files.

* ldlang.h (lang_input_statement_struct): Add stage1.
(cmdline_enum_type): New.
(cmdline_header_type): Likewise.
(cmdline_input_statement_type): Likewise.
(cmdline_claimed_output_type): Likewise.
(cmdline_union_type): Likewise.
(cmdline_list_type): Likewise.
(cmdline_list_append): Likewise.
(cmdline_list_insert_claimed_output): Likewise.
(cmdline_set_next_claimed_output): Likewise.

* ldmain.c (add_archive_element): Call
cmdline_set_next_claimed_output with archive BFD.  Set
BFD_PLUGIN for plugin.

* lexsup.c (ld_options): Add -flto and -flto-partition= for
GCC LTO option compatibility.
(parse_args): Call cmdline_list_append if needed.

* plugin.c (plugin_opt_plugin_arg): Ignore -pass-through=.
(add_input_file): Replace lang_add_input_file with
cmdline_list_insert_claimed_output.
(add_input_library): Likewise.

ld/testsuite/

2010-12-05  H.J. Lu  

PR ld/12248
* ld-plugin/func1i.c: New.
* ld-plugin/func2.c: Likewise.
* ld-plugin/func2h.c: Likewise.
* ld-plugin/func3p.c: Likewise.

* ld-plugin/plugin.exp: Add object files for symbols claimed
or created by testplugin.
* ld-plugin/plugin-7.d: Updated.
* ld-plugin/plugin-8.d: Likewise.
* ld-plugin/plugin-9.d: Likewise.

diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index e7805b6..10dbe83 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -5085,14 +5085,17 @@ struct bfd
   /* Decompress sections in this BFD.  */
 #define BFD_DECOMPRESS 0x1
 
+  /* This BFD has been processed by the linker plugin.  */
+#define BFD_PLUGIN 0x2
+
   /* Flags bits to be saved in bfd_preserve_save.  */
 #define BFD_FLAGS_SAVED \
-  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS)
+  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_PLUGIN)
 
   /* Flags bits which are for BFD use only.  */
 #define BFD_FLAGS_FOR_BFD_USE_MASK \
   (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_LINKER_CREATED

gcc-4.3-20101205 is now available

2010-12-05 Thread gccadmin 
Snapshot gcc-4.3-20101205 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 167472

You'll find:

 gcc-4.3-20101205.tar.bz2 Complete GCC (includes all of below)

  MD5=8b6e0be6aa0b6626a2ac85cb373d1b7c
  SHA1=98556f79514de3af6b0b4c3d55b73a4cc25f10d8

 gcc-core-4.3-20101205.tar.bz2C front end and core compiler

  MD5=05062081dbef44d96ffef367a7e6ebb8
  SHA1=af16ce3d9a9be80d5a1ae4ac65d01c1ef8fe3132

 gcc-ada-4.3-20101205.tar.bz2 Ada front end and runtime

  MD5=c9c9f9e70f1092eb3ab50b1b76aa5b4a
  SHA1=51fb103e33e3a0f80766adcc78d360ab639a84cb

 gcc-fortran-4.3-20101205.tar.bz2 Fortran front end and runtime

  MD5=ad329437a2a0042609014387bcb30687
  SHA1=9763f46b0fb6a2ec1b9d971bd4ee3448e25e0044

 gcc-g++-4.3-20101205.tar.bz2 C++ front end and runtime

  MD5=a7c213ebaeb911df703e37899ec1e742
  SHA1=79f67b36d62624ed643bcbacb1b25f0e289762ae

 gcc-java-4.3-20101205.tar.bz2Java front end and runtime

  MD5=4b474b97d0650ddffdc114e1cfc779ee
  SHA1=ae19a22e57fa66087c9ff031ba94fb6a15120251

 gcc-objc-4.3-20101205.tar.bz2Objective-C front end and runtime

  MD5=bf6b957c065af3d35999e4cde6c28773
  SHA1=d0d1d11b771b2ec3cfb4031f9cc0031252941fe2

 gcc-testsuite-4.3-20101205.tar.bz2   The GCC testsuite

  MD5=37a7d4e31c72ffbb31fb9defd0d0b491
  SHA1=c743d9c7aa116816dea158fa2f1627fc066c94b9

Diffs from 4.3-20101128 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: build_int_cstu does not work as advertised

2010-12-05 Thread Joseph S. Myers 
On Sun, 5 Dec 2010, Florian Weimer wrote:

> And is HOST_WIDE_INT guaraunteed to be able to hold 64 bits?  I recall

Only for targets that set need_64bit_hwint in config.gcc; for other 
targets, it depends on the host.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [Patch,quadmath] PR 46543: Add first documentation

2010-12-05 Thread Tobias Burnus 

Joseph S. Myers wrote:

On Tue, 30 Nov 2010, Tobias Burnus wrote:
[->  http://gcc.gnu.org/ml/fortran/2010-11/msg00413.html ]

This is a follow up / rediff to my previous patch at
http://gcc.gnu.org/ml/fortran/2010-11/msg00339.html, incorporating the
comments by Ralf and Matthias.

I think you have misunderstood.  If you don't have a license text then
there is no permission to distribute the document at all.  You need to
include a notice about GFDL licensing, and the text of the GFDL.


Updated patch attached. Other changes: Support --with-bugurl,  fixed 
AC_ARG_ENABLE usage and remove LICENSES from this patch (into a separate 
patch).


OK?

Tobias
2010-12-05  Tobias Burnus  

	PR fortran/46543
	* configure.ac: Add texinfo checks.
	* Makefile.am: Handle .texi documentation.
	* libquadmath.texi: New.
	* configure: Regenerated.
	* Makefile.in: Regenerated.

Index: Makefile.am
===
--- Makefile.am	(Revision 167472)
+++ Makefile.am	(Arbeitskopie)
@@ -105,4 +105,46 @@
 
 MAKEOVERRIDES=
 
+# AM_CONDITIONAL on configure option --generated-files-in-srcdir
+if GENINSRC
+STAMP_GENINSRC = stamp-geninsrc
+else
+STAMP_GENINSRC =
 endif
+
+# AM_CONDITIONAL on configure check ACX_CHECK_PROG_VER([MAKEINFO])
+if BUILD_INFO
+STAMP_BUILD_INFO = stamp-build-info
+else
+STAMP_BUILD_INFO =
+endif
+
+
+all-local: $(STAMP_GENINSRC)
+
+stamp-geninsrc: libquadmath.info
+	cp -p $(top_builddir)/libquadmath.info $(srcdir)/libquadmath.info
+	@touch $@
+
+libquadmath.info: $(STAMP_BUILD_INFO)
+
+stamp-build-info: libquadmath.texi
+	$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) -o libquadmath.info $(srcdir)/libquadmath.texi
+	@touch $@
+
+CLEANFILES = $(STAMP_GENINSRC) $(STAMP_BUILD_INFO) libquadmath.info
+MAINTAINERCLEANFILES = $(srcdir)/libquadmath.info
+
+endif
+
+
+# Automake Documentation:
+# If your package has Texinfo files in many directories, you can use the
+# variable TEXINFO_TEX to tell Automake where to find the canonical
+# `texinfo.tex' for your package. The value of this variable should be
+# the relative path from the current `Makefile.am' to `texinfo.tex'.
+TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex
+
+# Defines info, dvi, pdf and html targets
+MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include
+info_TEXINFOS = libquadmath.texi
Index: configure.ac
===
--- configure.ac	(Revision 167472)
+++ configure.ac	(Arbeitskopie)
@@ -41,6 +41,14 @@
 
 GCC_NO_EXECUTABLES
 
+# See if makeinfo has been installed and is modern enough
+# that we can use it.
+ACX_CHECK_PROG_VER([MAKEINFO], [makeinfo], [--version],
+   [GNU texinfo.* \([0-9][0-9.]*\)],
+   [4.[4-9]*|4.[1-9][0-9]*|[5-9]*|[1-9][0-9]*])
+AM_CONDITIONAL(BUILD_INFO, test $gcc_cv_prog_makeinfo_modern = "yes")
+
+
 # Configure libtool
 AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
@@ -186,5 +194,32 @@
   multilib_arg=
 fi
 
+
+# We would like our source tree to be readonly. However when releases or
+# pre-releases are generated, the flex/bison generated files as well as the
+# various formats of manuals need to be included along with the rest of the
+# sources.  Therefore we have --enable-generated-files-in-srcdir to do 
+# just that.
+AC_MSG_CHECKING(generated-files-in-srcdir)
+AC_ARG_ENABLE(generated-files-in-srcdir,
+[  --enable-version-specific-runtime-libsSpecify that runtime libraries should be installed in a compiler-specific directory ],
+[case "$enableval" in
+ yes) version_specific_libs=yes ;;
+ no)  version_specific_libs=no ;;
+ *)   AC_MSG_ERROR([Unknown argument to enable/disable generated-files-in-srcdir]);;
+ esac],
+[version_specific_libs=no])
+AC_ARG_ENABLE(generated-files-in-srcdir,
+[  --enable-generated-files-in-srcdir   put copies of generated files in source dir intended for creating source tarballs for users without texinfo bison or flex],
+[case "$enableval" in
+ yes) enable_generated_files_in_srcdir=yes ;;
+ no)  enable_generated_files_in_srcdir=no ;;
+ *)   AC_MSG_ERROR([Unknown argument to enable/disable version-specific libs]);;
+ esac],
+[enable_generated_files_in_srcdir=no])
+AC_MSG_RESULT($enable_generated_files_in_srcdir)
+AM_CONDITIONAL(GENINSRC, test "$enable_generated_files_in_srcdir" = yes)
+
+
 AC_CONFIG_FILES(Makefile)
 AC_OUTPUT
Index: libquadmath.texi
===
--- libquadmath.texi	(Revision 0)
+++ libquadmath.texi	(Revision 0)
@@ -0,0 +1,291 @@
+\input texinfo @c -*-texinfo-*-
+
+...@c %**start of header
+...@setfilename libquadmath.info
+...@settitle GCC libquadmath
+...@c %**end of header
+
+...@copying
+Copyright @copyright{} 2011 Free Software Foundation, Inc.
+
+...@quotation
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no
+Invariant Sections,

A possible super feature to add to gcc

2010-12-05 Thread Aspertame Man 

 Back in the 1970's when we ran fortran on an IBM machine we had this
 really powerful command called CALL FDUMP that if inserted into a
 program would send the names and values of every variable, at the time
 of its call, to a printer or file. In my opinion this was much more
 useful at times than a symbolic debugger, in scientific number crunching
 applications.
 
  If gcc does not have a similar function call I feel there would be
 people using gcc in the scientific community that very well might
 appreciate CALL FDUMP being resurrected.

Re: A possible super feature to add to gcc

2010-12-05 Thread Basile Starynkevitch 
On Sun, 05 Dec 2010 14:30:40 -0600
Aspertame Man  wrote:

> 
>  Back in the 1970's when we ran fortran on an IBM machine we had this
>  really powerful command called CALL FDUMP that if inserted into a
>  program would send the names and values of every variable, at the time
>  of its call, to a printer or file. In my opinion this was much more
>  useful at times than a symbolic debugger, in scientific number crunching
>  applications.
>  
>   If gcc does not have a similar function call I feel there would be
>  people using gcc in the scientific community that very well might
>  appreciate CALL FDUMP being resurrected. 

You probably are thinking of a new builtin or intrinsic function.
It could be interesting, but it probably is not of general interest to
the entire GCC community (which these days is quite conservative on the
language extensions it accept).

That could be an interesting project for a GCC plugin or a GCC MELT
(see www.gcc-melt.org or http://gcc.gnu.org/wiki/MELT for more)
extension. Maybe your company could fund someone (perhaps starting with
a very good intern interested) to do such work. I would imagine that it
could take a few months (at least for a person not extremly familiar
with GCC internals). 

If you fund an intern to explore doing the work using GCC MELT, I would
be delighted to help him on the MELT specific.

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Richard Guenther 
On Sun, Dec 5, 2010 at 6:49 PM, Chris Lattner  wrote:
>
> On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
>
>>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm 
>>> -show-mc-encoding
>>>        .section        __TEXT,__text,regular,pure_instructions
>>>        .globl  __Z4testl
>>>        .align  4, 0x90
>>> __Z4testl:                              ## @_Z4testl
>>> ## BB#0:                                ## %entry
>>>        movl    $4, %ecx                ## encoding: 
>>> [0xb9,0x04,0x00,0x00,0x00]
>>>        movq    %rdi, %rax              ## encoding: [0x48,0x89,0xf8]
>>>        mulq    %rcx                    ## encoding: [0x48,0xf7,0xe1]
>>>        movq    $-1, %rdi               ## encoding: 
>>> [0x48,0xc7,0xc7,0xff,0xff,0xff,0xff]
>>>        cmovnoq %rax, %rdi              ## encoding: [0x48,0x0f,0x41,0xf8]
>>>        jmp     __Znam                  ## TAILCALL
>>>                                        ## encoding: [0xeb,A]
>>>                                        ##   fixup A - offset: 1, value: 
>>> __Znam-1, kind: FK_PCRel_1
>>> .subsections_via_symbols
>>>
>>> This could be further improved by inverting the cmov condition to avoid the 
>>> first movq, which we'll tackle as a general regalloc improvement.
>>
>> I'm curious as on how you represent the overflow checking in your highlevel 
>> IL.
>
> The (optimized) generated IR is:
>
> $ clang t.cc -emit-llvm -S -o - -O3
> ...
> define noalias i8* @_Z4testl(i64 %count) ssp {
> entry:
>  %0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
>  %1 = extractvalue %0 %0, 1
>  %2 = extractvalue %0 %0, 0
>  %3 = select i1 %1, i64 -1, i64 %2
>  %call = tail call noalias i8* @_Znam(i64 %3)
>  ret i8* %call
> }
>
> More information on the overflow intrinsics is here:
> http://llvm.org/docs/LangRef.html#int_overflow

Ah, you're using intrinsics.  I thought of re-using the saturating arithmetic
and types we have, thus basically do

  size = (unsigned sat int) count * 4;

and defer optimal expansion to an optab.  It of course requires saturating
arithmetic emulation for targets that don't provide an expander but would
allow optimal expansion at least.

And it'll unleash all the latent bugs we have with saturating types ...

Richard.

> -Chris

Re: build_int_cstu does not work as advertised

2010-12-05 Thread Richard Guenther 
On Sun, Dec 5, 2010 at 6:08 PM, Florian Weimer  wrote:
> Trunk has this:
>
> | /* Create an INT_CST node with a CST value zero extended.  */
> |
> | static inline tree
> | build_int_cstu (tree type, unsigned HOST_WIDE_INT cst)
> | {
> |   return double_int_to_tree (type, uhwi_to_double_int (cst));
> | }
>
> But the comment is misleading because of:

Well, you shouldn't call it with signed or sign-extended types ...

> | /* Constructs tree in type TYPE from with value given by CST.  Signedness
> |    of CST is assumed to be the same as the signedness of TYPE.  */
> |
> | tree
> | double_int_to_tree (tree type, double_int cst)
> | {
> |   /* Size types *are* sign extended.  */
> |   bool sign_extended_type = (!TYPE_UNSIGNED (type)
> |                            || (TREE_CODE (type) == INTEGER_TYPE
> |                                && TYPE_IS_SIZETYPE (type)));
> |
> |   cst = double_int_ext (cst, TYPE_PRECISION (type), !sign_extended_type);
> |
> |   return build_int_cst_wide (type, cst.low, cst.high);
> | }
>
> So for size types, build_int_cstu does not peform zero extension, but
> sign extension.

And that's correct.

> If I don't want sign extension, what function should I use instead?
> Should I just call build_int_cst_wide directly?

You should use a different type, one that is not sign-extended.  Non-canonical
constants are not allowed as we share them based on type and value.

> And is HOST_WIDE_INT guaraunteed to be able to hold 64 bits?  I recall
> a discussion were it was said that cross-builds from hosts with narrow
> HOST_WIDE_INT to 64 bit targets weren't supported.

double_int is at least 64 bits.

Richard.

Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Joseph S. Myers 
On Sun, 5 Dec 2010, Richard Guenther wrote:

> Ah, you're using intrinsics.  I thought of re-using the saturating arithmetic
> and types we have, thus basically do
> 
>   size = (unsigned sat int) count * 4;
> 
> and defer optimal expansion to an optab.  It of course requires saturating
> arithmetic emulation for targets that don't provide an expander but would
> allow optimal expansion at least.
> 
> And it'll unleash all the latent bugs we have with saturating types ...

And I thought that defining saturated operations for normal integer types 
would be better than trying to use fixed-point types on targets that don't 
have an ABI for them or where they may not match the types on which you 
want saturated operations.  That is, I think saturated operations would be 
a better internal representation at the GIMPLE level than saturated types 
(this may also apply to lowering existing fixed-point saturated type 
support) and then they could be expanded to various forms of RTL including 
direct saturated instructions, comparisons or overflow flags checks.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: operator new[] overflow (PR 19351)

2010-12-05 Thread Richard Guenther 
On Sun, Dec 5, 2010 at 10:21 PM, Joseph S. Myers
 wrote:
> On Sun, 5 Dec 2010, Richard Guenther wrote:
>
>> Ah, you're using intrinsics.  I thought of re-using the saturating arithmetic
>> and types we have, thus basically do
>>
>>   size = (unsigned sat int) count * 4;
>>
>> and defer optimal expansion to an optab.  It of course requires saturating
>> arithmetic emulation for targets that don't provide an expander but would
>> allow optimal expansion at least.
>>
>> And it'll unleash all the latent bugs we have with saturating types ...
>
> And I thought that defining saturated operations for normal integer types
> would be better than trying to use fixed-point types on targets that don't
> have an ABI for them or where they may not match the types on which you
> want saturated operations.  That is, I think saturated operations would be
> a better internal representation at the GIMPLE level than saturated types
> (this may also apply to lowering existing fixed-point saturated type
> support) and then they could be expanded to various forms of RTL including
> direct saturated instructions, comparisons or overflow flags checks.

True - but it's not how saturated operations are implemented in the
middle-end right now.  Eventually I will finish transitioning our undefined
overflow scheme to that for 4.7 though ...

Richard.

> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: build_int_cstu does not work as advertised

2010-12-05 Thread Florian Weimer 
* Richard Guenther:

>> If I don't want sign extension, what function should I use instead?
>> Should I just call build_int_cst_wide directly?
>
> You should use a different type, one that is not sign-extended.
> Non-canonical constants are not allowed as we share them based on
> type and value.

I find it a bit puzzling that GCC deems -1 a canonical constant for an
unsigned type (instead of the passed-in positive value), which leads
to misoptimizations further down the road.

In the meantime, I've realized that I should be using
TYPE_MAX_VALUE (size_type_node), so I think this particular
matter is resolved.

Re: [Patch,quadmath] PR 46543: Add first documentation

2010-12-05 Thread Andreas Schwab 
Tobias Burnus  writes:

> @@ -186,5 +194,32 @@
>multilib_arg=
>  fi
>  
> +
> +# We would like our source tree to be readonly. However when releases or
> +# pre-releases are generated, the flex/bison generated files as well as the
> +# various formats of manuals need to be included along with the rest of the
> +# sources.  Therefore we have --enable-generated-files-in-srcdir to do 
> +# just that.
> +AC_MSG_CHECKING(generated-files-in-srcdir)
> +AC_ARG_ENABLE(generated-files-in-srcdir,
> +[  --enable-version-specific-runtime-libsSpecify that runtime libraries 
> should be installed in a compiler-specific directory ],

Please use AS_HELP_STRING, and the help string should not be
capitalized.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A possible super feature to add to gcc

2010-12-05 Thread Joern Rennecke 

Quoting Aspertame Man :



 Back in the 1970's when we ran fortran on an IBM machine we had this
 really powerful command called CALL FDUMP that if inserted into a
 program would send the names and values of every variable, at the time
 of its call, to a printer or file. In my opinion this was much more
 useful at times than a symbolic debugger, in scientific number crunching
 applications.


I don't see how this would  be better than dumping core and resuming  
execution.

I suppose you might even do a fork before dumping core, that might speed up
if you have multiple CPU cores and copy-on-write memory semantics.

Re: PATCH: 2 stage BFD linker for LTO plugin

2010-12-05 Thread H.J. Lu 
On Sun, Dec 5, 2010 at 10:22 AM, H.J. Lu  wrote:
> On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu  wrote:
>> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu  wrote:
>>> On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu  wrote:
 On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu  wrote:
> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn  
> wrote:
>> On 04/12/2010 01:24, H.J. Lu wrote:
>>
>>> I checked in a patch to implement stage 2 linking. Everything
>>> seems to work, including "gcc -static ... -lm".
>>
>>  Any chance you could send a complete diff?
>>
>
> I will submit a complete diff after I fix a few corner cases.
> In the meantime, you can clone my git tree and do a "git diff".
>

 Hi,

 This patch implements 2 stage BFD linker for LTO plugin.
 It works with current LTO API on all cases I tested.

 Known issue:  --whole-archive will call plugin on archives with IR
 in stage 2 linking. But ld never calls plugin to get back object files.
 I will try to avoid it in a follow up patch.

>>>
>>> This turns out not a problem. In stage 2 linking, for --whole-archive
>>> we call plugin to get symbols in the IR element of an archive and
>>> it will be ignored for stage 2 linking.  It is OK since we already get
>>> the trans object files back for stage 2 linking.
>>>
>>> BTW, the new linker passed bootstrap-lto with all default languages.
>>> I am planning to include this patch in the next Linux binutils.
>>>
>>
>> I missed the IR object in an archive:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
>>
>> This updated patch fixed it.  OK for trunk?
>>
>
> We shouldn't clear SEC_EXCLUDE if BFD_PLUGIN is set:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c38
>
> This updated patch fixed it.  OK for trunk?
>

It turns out that my patch also fixes:

http://sourceware.org/bugzilla/show_bug.cgi?id=12277


-- 
H.J.

Re: PATCH: Properly convert LTO plugin visibility to ELF visibility

2010-12-05 Thread H.J. Lu 
On Sun, Dec 5, 2010 at 4:32 PM, Alan Modra  wrote:
> On Sun, Dec 05, 2010 at 04:01:51PM -0800, H.J. Lu wrote:
>> Hi,
>>
>> The order of LTO plugin visibility is different from ELF visibility.
>
> Daft.  Can't we fix that now, before 2.21 and gcc-4.6 are released?

I guess it is too late to change the plugin API.

>> I checked in this patch to fix it.
>>
>>
>> H.J.
>> ---
>> diff --git a/ld/ChangeLog b/ld/ChangeLog
>> index 66aee40..bfef25a 100644
>> --- a/ld/ChangeLog
>> +++ b/ld/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2010-12-05  H.J. Lu  
>> +
>> +     * plugin.c (asymbol_from_plugin_symbol): Proper translate
>> +     LTO plugin visibility to ELF visibility.
>> +     (is_visible_from_outside): Re-indent.
>
> Please put PR ld/12277 on the ChangeLog entry.

Done.

>> +       einfo (_("%P%F: unknown ELF symbol visibility: %d!"),
>> +              ldsym->visibility);
>
> einfo needs a trailing \n on the message string.
>

I checked in the enclosed patch.

Thanks.


-- 
H.J.
---
2010-12-05  H.J. Lu  

* plugin.c (asymbol_from_plugin_symbol): Add the trailing `\n'
to einfo.
(get_symbols): Likewise.
(plugin_notice): Likewise.
(plugin_multiple_definition): Likewise.

diff --git a/ld/plugin.c b/ld/plugin.c
index ae9c378..8cc0270 100644
--- a/ld/plugin.c
+++ b/ld/plugin.c
@@ -310,11 +310,11 @@ asymbol_from_plugin_symbol (bfd *abfd, asymbol *asym,
   unsigned char visibility;

   if (!elfsym)
-   einfo (_("%P%F: %s: non-ELF symbol in ELF BFD!"), asym->name);
+   einfo (_("%P%F: %s: non-ELF symbol in ELF BFD!\n"), asym->name);
   switch (ldsym->visibility)
{
default:
- einfo (_("%P%F: unknown ELF symbol visibility: %d!"),
+ einfo (_("%P%F: unknown ELF symbol visibility: %d!\n"),
 ldsym->visibility);
case LDPV_DEFAULT:
  visibility = STV_DEFAULT;
@@ -476,7 +476,7 @@ get_symbols (const void *handle, int nsyms, struct
ld_plugin_symbol *syms)
  && blhe->type != bfd_link_hash_common)
{
  /* We should not have a new, indirect or warning symbol here.  */
- einfo ("%P%F: %s: plugin symbol table corrupt (sym type %d)",
+ einfo ("%P%F: %s: plugin symbol table corrupt (sym type %d)\n",
 called_plugin->name, blhe->type);
}

@@ -869,7 +869,7 @@ plugin_notice (struct bfd_link_info *info ATTRIBUTE_UNUSED,
   /* This is a ref from a non-IR file, so note the ref'd symbol
 in the non-IR-only hash.  */
   if (!bfd_hash_lookup (non_ironly_hash, name, TRUE, TRUE))
-   einfo (_("%P%X: %s: hash table failure adding symbol %s"),
+   einfo (_("%P%X: %s: hash table failure adding symbol %s\n"),
   abfd->filename, name);
 }
   else if (!is_ref && is_dummy)
@@ -902,10 +902,10 @@ plugin_multiple_definition (struct bfd_link_info
*info, const char *name,
   struct bfd_link_hash_entry *blhe
= bfd_link_hash_lookup (info->hash, name, FALSE, FALSE, FALSE);
   if (!blhe)
-   einfo (_("%P%X: %s: can't find IR symbol '%s'"), nbfd->filename,
+   einfo (_("%P%X: %s: can't find IR symbol '%s'\n"), nbfd->filename,
   name);
   else if (blhe->type != bfd_link_hash_defined)
-   einfo (_("%P%x: %s: bad IR symbol type %d"), name, blhe->type);
+   einfo (_("%P%x: %s: bad IR symbol type %d\n"), name, blhe->type);
   /* Replace it with new details.  */
   blhe->u.def.section = nsec;
   blhe->u.def.value = nval;

Re: PATCH: 2 stage BFD linker for LTO plugin

2010-12-05 Thread H.J. Lu 
On Sun, Dec 5, 2010 at 4:11 PM, H.J. Lu  wrote:
> On Sun, Dec 5, 2010 at 10:22 AM, H.J. Lu  wrote:
>> On Sat, Dec 4, 2010 at 4:43 PM, H.J. Lu  wrote:
>>> On Sat, Dec 4, 2010 at 9:34 AM, H.J. Lu  wrote:
 On Fri, Dec 3, 2010 at 10:07 PM, H.J. Lu  wrote:
> On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu  wrote:
>> On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn  
>> wrote:
>>> On 04/12/2010 01:24, H.J. Lu wrote:
>>>
 I checked in a patch to implement stage 2 linking. Everything
 seems to work, including "gcc -static ... -lm".
>>>
>>>  Any chance you could send a complete diff?
>>>
>>
>> I will submit a complete diff after I fix a few corner cases.
>> In the meantime, you can clone my git tree and do a "git diff".
>>
>
> Hi,
>
> This patch implements 2 stage BFD linker for LTO plugin.
> It works with current LTO API on all cases I tested.
>
> Known issue:  --whole-archive will call plugin on archives with IR
> in stage 2 linking. But ld never calls plugin to get back object files.
> I will try to avoid it in a follow up patch.
>

 This turns out not a problem. In stage 2 linking, for --whole-archive
 we call plugin to get symbols in the IR element of an archive and
 it will be ignored for stage 2 linking.  It is OK since we already get
 the trans object files back for stage 2 linking.

 BTW, the new linker passed bootstrap-lto with all default languages.
 I am planning to include this patch in the next Linux binutils.

>>>
>>> I missed the IR object in an archive:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
>>>
>>> This updated patch fixed it.  OK for trunk?
>>>
>>
>> We shouldn't clear SEC_EXCLUDE if BFD_PLUGIN is set:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c38
>>
>> This updated patch fixed it.  OK for trunk?
>>
>
> It turns out that my patch also fixes:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>

Updated patch, adjusted for plugin ELF symbol visibility bug fix.
OK for trunk?

Thanks.


-- 
H.J.
bfd/

2010-12-05  H.J. Lu  

PR ld/12248
PR ld/12277
* bfd.c (BFD_PLUGIN): New.
(BFD_FLAGS_SAVED): Add BFD_PLUGIN.
(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.

* bfd-in2.h: Regenerated.

ld/

2010-12-05  H.J. Lu  

PR ld/12248
PR ld/12277
* ldfile.c (ldfile_try_open_bfd): Set BFD_PLUGIN for plugin. Set
stage1.

* ldlang.c (cmdline_list): New.
(cmdline_next_claimed_output): Likewise.
(cmdline_list_init): Likewise.
(cmdline_get_stage2_input_files): Likewise.
(debug_cmdline_list): Likewise.
(cmdline_list_append): Likewise.
(cmdline_set_next_claimed_output): Likewise.
(cmdline_list_insert_claimed_output): Likewise.
(new_afile): Set stage1 to FALSE;
(lang_init): Call cmdline_list_init.
(lang_gc_sections): Don't clear SEC_EXCLUDE if BFD_PLUGIN is
set.
(lang_process): Call plugin_active_plugins_p to check plugin
support.  Check cmdline_next_claimed_output before opening
stage 2 input.  Call debug_cmdline_list if trace_file_tries
is set.  Call cmdline_get_stage2_input_files to get stage 2
input files.

* ldlang.h (lang_input_statement_struct): Add stage1.
(cmdline_enum_type): New.
(cmdline_header_type): Likewise.
(cmdline_input_statement_type): Likewise.
(cmdline_claimed_output_type): Likewise.
(cmdline_union_type): Likewise.
(cmdline_list_type): Likewise.
(cmdline_list_append): Likewise.
(cmdline_list_insert_claimed_output): Likewise.
(cmdline_set_next_claimed_output): Likewise.

* ldmain.c (add_archive_element): Call
cmdline_set_next_claimed_output with archive BFD.  Set
BFD_PLUGIN for plugin.

* lexsup.c (ld_options): Add -flto and -flto-partition= for
GCC LTO option compatibility.
(parse_args): Call cmdline_list_append if needed.

* plugin.c (plugin_opt_plugin_arg): Ignore -pass-through=.
(add_input_file): Replace lang_add_input_file with
cmdline_list_insert_claimed_output.
(add_input_library): Likewise.

ld/testsuite/

2010-12-05  H.J. Lu  

PR ld/12248
PR ld/12277
* ld-plugin/func1p.c: New.
* ld-plugin/func2.c: Likewise.
* ld-plugin/func2i.c: Likewise.
* ld-plugin/func3h.c: Likewise.

* ld-plugin/plugin.exp: Add object files for symbols claimed
or created by testplugin.
* ld-plugin/plugin-7.d: Updated.
* ld-plugin/plugin-8.d: Likewise.
* ld-plugin/plugin-9.d: Likewise.

diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index e7805b6..10dbe83 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -5085,14 +5085,17 @@ struct bfd
   /* Decompress sections in this BFD.  */
 #define BFD_DECOMPRESS 0x1

Built gcc 4.5.1 on amd64-unknown-openbsd4.8

2010-12-05 Thread Kyle Markley 

Hello,

Following the recommendations on 
http://gcc.gnu.org/install/finalinstall.html, I'm reporting my success 
at building gcc 4.5.1 on amd64-unknown-openbsd4.8 because this platform 
is not listed in http://gcc.gnu.org/buildstat.html.


$ ./config.guess
amd64-unknown-openbsd4.8

$ /tmp/usr/local/bin/g++-4.5.1 -v
Using built-in specs.
COLLECT_GCC=/tmp/usr/local/bin/g++-4.5.1
COLLECT_LTO_WRAPPER=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-openbsd4.8/4.5.1/lto-wrapper
Target: x86_64-unknown-openbsd4.8
Configured with: ../gcc/configure --program-suffix=-4.5.1 
--enable-threads --enable-languages=c++ : (reconfigured) 
../gcc/configure --program-suffix=-4.5.1 --enable-threads 
--enable-languages=c++

Thread model: posix
gcc version 4.5.1 (GCC)


I found that gcc was difficult to build on this platform.  I started 
from the patches included with my OpenBSD 4.8 distribution's ports tree 
for gcc 4.3.  Many of these patches do not apply cleanly to the source 
code of 4.5.1 (due to code drift since 4.3) and I had to make many of 
the changes manually.  The most important patches were to gcc/config.gcc 
and libgcc/config.host so that my platform was recognized, and several 
changes in gcc/config/, but the patches from the ports tree got me most 
of the way through.


Finally, I hit this bug while building:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618
... but killing the process (as recommended at that link) let me 
proceed.



I don't think I have the expertise necessary to help maintain the 
health of gcc on OpenBSD for the long run, but I am interested in 
helping to make it easier to build on this platform.  Please let me know 
what I can do.


--
Kyle Markley