Re: C provenance semantics proposal

[Ralf Jung]

Hi all,

>>>  if (a == b)
>>> ...
>>>
>>>  # c = PHI 
>>>
>>> where we'd lose eliding such a conditional.  IMHO that's bad
>>> and very undesirable.
>> But if we only suppress this optimization for pointers is it that terrible?
> 
> I've at least seen a lot of cases with c = PHI  for null pointer
> checks.  It's just we're going to chase a lot of cases down even
> knowing RTL will fuck up later big times.

Even if pointer substitution based on "==" is not possible in general, it can
still be possible (depending on other choices in the IR semantics) to do
substitution for "== NULL" pointer tests.  This is the conclusion we came to
when studying similar questions for LLVM IR in
.

Kind regards,
Ralf

Re: [9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken (was: GCC 9.0.1 Status Report (2019-04-25))

[Ilya Verbin]

Hi Hongtao,

I have left Intel 3 years ago. If you have any questions regarding MIC
offloading, you can reach me by iver...@gmail.com

Hongtao Liu :
> I don't konw this guy ilya.ver...@intel.com.
> Do you know him/her, H.J?
>
> --
> BR,
> Hongtao

  || Ilya

Re: About GSOC.

[Joseph Myers]

On Wed, 8 May 2019, Tejas Joshi wrote:

> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.

This patch still has problems.  You can't assume that all of sig[0] and 
sig[1] are below the 0.5 bit.  You have to allow for the 0.5 bit possibly 
being in any word of the significand, not necessarily the SIGSZ - 1 word, 
meaning you have to loop over all words of the significand.  A word 
completely below the 0.5 bit can just be checked for being 0.  A word 
containing the 0.5 bit needs checking both the bits in that word below the 
0.5 bit, and checking that the 0.5 bit is 1.

REAL_EXP (r) could be bigger than SIGNIFICAND_BITS, so you need to handle 
that case (automatically an integer) rather than computing a spurious very 
large n.

This should illustrate testcases that need adding, to cover the various 
cases of where the 0.5 bit is and where any nonzero bit below it might be 
- my suggestion is to add such tests, make sure they fail with your 
existing patch, and only then fix the implementation to make them pass.  
For some of those tests, you'll need to test long double or _Float128.  
(Use DEF_EXT_LIB_FLOATN_NX_BUILTINS in builtins.def to add the built-in 
function variants such as roundevenf128; existing round-to-integer 
functions already have such variants.)

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

Re: About GSOC.

[Joseph Myers]

On Wed, 8 May 2019, Tejas Joshi wrote:

> Is this the way test cases should be added and checked?

Yes, that's appropriate for tests of roundeven optimization for constant 
arguments.

When you get onto testing roundevenf128 (to cover various cases with 
113-bit precision), you'll need to make those tests appropriately 
conditional on _Float128 support being available - either use "#ifdef 
__FLT128_MAX__" within the test, or have a separate test for those cases 
and use

/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

in that test.  ({ dg-add-options float128 } allows _Float128 tests to be 
run in configurations that only support _Float128 with some command-line 
options.)

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

gcc-7-20190509 is now available

[gccadmin]

Snapshot gcc-7-20190509 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190509/
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/branches/gcc-7-branch 
revision 271046

You'll find:

 gcc-7-20190509.tar.xzComplete GCC

  SHA256=2fef037bc34d7b489822fe759de5032d2fe80391cfe318ad3d0cc56dc6564dd5
  SHA1=cdb9a4809345270ab4d0425d94365864c16cb35b

Diffs from 7-20190502 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.