DLLTool put wrong hint value in lib archieve (GCC 6.2)

2016-11-13 Thread Rudy 
I'm email this, since I can't register in your bug report forum, its
because my IP I think.

I just want to report that DLLTool put wrong hint value in lib
archieve (IDATA6 section).
In "make_one_lib_file" function, I see the hint value grab from
"{struct}export->hint",
instead it should grab from "{struct}export->ordinal".

Don't worry about the value in "{struct}export->ordinal",
"fill_ordinals" function take good care of it.
And "{struct}export->hint" should be erase since no function used that
value anywhere in "dlltool.c" except for
"make_one_lib_file" function.
The generate object file name in lib archive already take care by
"gen_lib_file" function.

so it should change like this in "dlltool.c" for "make_one_lib_file"
function (case IDATA6):
[-] Original: LINE 2781: int idx = exp->hint;
[+] Patch   : LINE 2781: int idx = exp->ordinal;

The patch for "dlltool.c" to remove "{struct}export->hint":
[-] typedef struct export:   LINE 785:   REMOVE THIS -> int hint;
[-] "gen_lib_file" function: LINE 3265:  REMOVE THIS ->
alias_exp.hint = exp->hint;
[-] "mangle_defs" function:  LINE 3931:  REMOVE THIS -> int hint = 0;
[-] "mangle_defs" function:  LINE 3961-3964: REMOVE ALL OF THIS ->
for (i = 0; i < d_nfuncs; i++)
if (!d_exports_lexically[i]->noname || show_allnames)
  d_exports_lexically[i]->hint = hint++;

Thanks.

gcc-7-20161113 is now available

2016-11-13 Thread gccadmin 
Snapshot gcc-7-20161113 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20161113/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 242368

You'll find:

 gcc-7-20161113.tar.bz2   Complete GCC

  MD5=991519c601992c0270aba3e6d218d416
  SHA1=ab3b1c5404e9ad7442d370c1530b055e6e1df90b

Diffs from 7-20161106 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
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: anti-ranges of signed variables

2016-11-13 Thread kugan 

Hi,

On 12/11/16 06:19, Jakub Jelinek wrote:

On Fri, Nov 11, 2016 at 11:51:34AM -0700, Martin Sebor wrote:

On 11/11/2016 10:53 AM, Richard Biener wrote:

On November 11, 2016 6:34:37 PM GMT+01:00, Martin Sebor  
wrote:

I noticed that variables of signed integer types that are constrained
to a specific subrange of values of the type like so:

[-TYPE_MAX + N, N]

are reported by get_range_info as the anti-range

[-TYPE_MAX, TYPE_MIN - 1]

for all positive N of the type regardless of the variable's actual
range.  Basically, such variables are treated the same as variables
of the same type that have no range info associated with them at all
(such as function arguments or global variables).

For example, while a signed char variable between -1 and 126 is
represented by

VR_ANTI_RANGE [127, -2]


? I'd expect [-1, 126].  And certainly never range-min > range-max


Okay.  With this code:

  void f (void *d, const void *s, signed char i)
  {
if (i < -1 || 126 < i) i = -1;
__builtin_memcpy (d, s, i);
  }

I see the following in the output of -fdump-tree-vrp:

  prephitmp_11: ~[127, 18446744073709551614]
  ...
  # prephitmp_11 = PHI <_12(3), 18446744073709551615(2)>
  __builtin_memcpy (d_8(D), s_9(D), prephitmp_11);


At some point get_range_info for anti-ranges has been represented
by using min larger than max, but later on some extra bit on SSA_NAME has
been added.  Dunno if the code has been adjusted at that point.


Commit changed that and removed it is.
commit 0c20fe492bc5b8c9259d21dd2dab03ff5155facb
Author: rsandifo 
Date:   Thu Nov 28 16:32:44 2013 +

wide-int version of SSA_NAME_ANTI_ALIAS_P patch.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@205491 
138bc75d-0d04-0410-961f-82ee72b054a4



But looking closely:

enum value_range_type { VR_UNDEFINED, VR_RANGE,
VR_ANTI_RANGE, VR_VARYING, VR_LAST };
in set_range_info, we have:
  SSA_NAME_ANTI_RANGE_P (name) = (range_type == VR_ANTI_RANGE);

in get_range_info, we have:
  return SSA_NAME_RANGE_TYPE (name);

I think we should change the get_range_info to:

diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
index 913d142..f33b9c0 100644
--- a/gcc/tree-ssanames.c
+++ b/gcc/tree-ssanames.c
@@ -371,7 +371,7 @@ get_range_info (const_tree name, wide_int *min, 
wide_int *max)


   *min = ri->get_min ();
   *max = ri->get_max ();
-  return SSA_NAME_RANGE_TYPE (name);
+  return SSA_NAME_RANGE_TYPE (name) ? VR_ANTI_RANGE : VR_RANGE;
 }

Is this OK after testing ?

Thanks,
Kugan

Re: anti-ranges of signed variables

2016-11-13 Thread kugan 




I think we should change the get_range_info to:

diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
index 913d142..f33b9c0 100644
--- a/gcc/tree-ssanames.c
+++ b/gcc/tree-ssanames.c
@@ -371,7 +371,7 @@ get_range_info (const_tree name, wide_int *min,
wide_int *max)

*min = ri->get_min ();
*max = ri->get_max ();
-  return SSA_NAME_RANGE_TYPE (name);
+  return SSA_NAME_RANGE_TYPE (name) ? VR_ANTI_RANGE : VR_RANGE;
  }


OK, this is what SSA_NAME_RANGE_TYPE in tree.h is doing.
#define SSA_NAME_RANGE_TYPE(N) \
(SSA_NAME_ANTI_RANGE_P (N) ? VR_ANTI_RANGE : VR_RANGE)

So, we shouldn't do it again. Sorry about the noise.

Kugan

Re: anti-ranges of signed variables

2016-11-13 Thread Jakub Jelinek 
On Mon, Nov 14, 2016 at 02:13:51PM +1100, kugan wrote:
> I think we should change the get_range_info to:
> 
> diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
> index 913d142..f33b9c0 100644
> --- a/gcc/tree-ssanames.c
> +++ b/gcc/tree-ssanames.c
> @@ -371,7 +371,7 @@ get_range_info (const_tree name, wide_int *min, wide_int
> *max)
> 
>*min = ri->get_min ();
>*max = ri->get_max ();
> -  return SSA_NAME_RANGE_TYPE (name);
> +  return SSA_NAME_RANGE_TYPE (name) ? VR_ANTI_RANGE : VR_RANGE;

Why?

#define SSA_NAME_RANGE_TYPE(N) \
(SSA_NAME_ANTI_RANGE_P (N) ? VR_ANTI_RANGE : VR_RANGE)

>  }
> 
> Is this OK after testing ?

No.

Jakub