Re: GCC 9.2 Release Candidate available from gcc.gnu.org

[Iain Sandoe]

> On 5 Aug 2019, at 17:30, Bill Seurer  wrote:
> 
> On 8/5/19 8:16 AM, Jakub Jelinek wrote:
>> The first release candidate for GCC 9.2 is available from
>>  https://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805/
>>  ftp://gcc.gnu.org/pub/gcc/snapshots/9.2.0-RC-20190805
>> and shortly its mirrors.  It has been generated from SVN revision 274111.
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux and i686-linux.  Please test it and report any issues to
>> bugzilla.
>> If all goes well, I'd like to release 9.2 on Monday, August 12th.
> 
> I bootstrapped and tested powerpc64 BE on power 7 and power 8 and powerpc64 
> LE on power 8 and power 9 and all looks well.

I bootstrapped and tested 274111 on i686,powerpc-darwin9, x86_64-darwin16,17,18 
(posted results), notable is that for the first time (ever?) powerpc-darwin9 
reports 0 Ada fails.
i686-darwin10 and x86_64-darwin15 bootstrapped, but testing is not yet complete.
Iain

Re: GCC 9.2 Status Report (2019-08-05), branch frozen for release

[Jakub Jelinek]

On Mon, Aug 05, 2019 at 11:03:02AM -0600, Martin Sebor wrote:
> On 8/5/19 7:21 AM, Jakub Jelinek wrote:
> > Status
> > ==
> > 
> > The first 9.2 release candidate has been released.
> > The GCC 9 branch is frozen for preparation of the GCC 9.2 release.
> > All changes to the branch now require release manager approval.
> 
> Can I get an approval to backport the fix for pr90947 - [9 Regression]
> Simple lookup table of array of strings is miscompiled​?

That would require another rc.  Unless we are forced to do it anyway for
other more urgent reasons, I'd prefer to defer for 9.3, you can test now but
commit after the release.

Jakub

Re: [GSoC-19] Implementing narrowing functions like fadd

[Tejas Joshi]

Hello.
I have come up with the testcases for fadd variants and the following
patch comes with them. Again, the patch follows the points mentioned
above and if good to go, I will post it to the gcc-patches. The patch
bootstraps and survives regression tests.

Thanks,
Tejas

On Fri, 2 Aug 2019 at 16:10, Tejas Joshi  wrote:
>
> Hello.
> I have made this patch strictly considering the following points
> Joseph mentioned in his initial email :
>
> > * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
> > from most other built-in math.h functions because the return type is
> > different from the argument types.  You could start by adding them to
> > builtins.def similarly to roundeven (with new macros to handle adding such
> > functions for relevant pairs of _FloatN, _FloatNx types).  These functions
> > could be folded for constant arguments only if the result is exact, or if
> > -fno-rounding-math -fno-trapping-math (and -fno-math-errno if the result
> > involves overflow / underflow).
>
> I am trying to come up with testcases which would work around
> -fno-rounding-math -fno-trapping-math and -fno-math-errno while
> considering inexact and overlfow/underflow cases. I will try them as
> soon as possible and send another patch with them and after regression
> testing. Apart from that, am I missing something in this patch?
>
> Thanks,
> Tejas
>
>
> On Wed, 31 Jul 2019 at 12:06, Tejas Joshi  wrote:
> >
> > Hello.
> >
> > > fold_const_fadd), for example I am not sure what the return values are
> > > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > > done for now
> >
> > I modeled real_fadd function on a similar function, real_nextafter
> > which would take three arguments. Just as overflow and underflow
> > conditions are handled there, I thought similarly if exact/inexact and
> > overflow/underflow conditions would be handled by fold_const_fadd for
> > real_fadd. As these conditions are still need to be addressed (so
> > current function is prototypish), is real_nextafter a good model to
> > refer?
> >
> > > I am not sure I understand your question, you have used real_convert in
> > > real_fadd and it seems to be doing exactly that?  As you know I am not
> >
> > Looking at different comments where real_convert is used, I guessed it
> > formats GCC's floating point format to a target format rather than
> > converting to return type. Its still unclear to me but its good if it
> > does convert to return type like it seems. I am working on these
> > conditions now and will try to come up with testcases.
> >
> > Thanks,
> > Tejas
> >
> >
> > On Mon, 29 Jul 2019 at 22:47, Martin Jambor  wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Jul 27 2019, Tejas Joshi wrote:
> > > > Hello.
> > > >
> > > >>> You'll need something different from CASE_MATHFN - these are a 
> > > >>> different
> > > >>> kind of functions that need handling in a different way, because they 
> > > >>> are
> > > >>> parametrized over certain *pairs* of types, rather than over a single
> > > >>> type.
> > > >> first phase, please just directly test for in the code for
> > > >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> > > >> those here to get a prototype working.  When you add support for more
> > > >
> > > > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> > > > following patch and function is getting folded.
> > >
> > > good.  Please add comments to functions which miss them (real_fadd and
> > > fold_const_fadd), for example I am not sure what the return values are
> > > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > > done for now - after you implement fsub, fmul and fdiv(?) you might want
> > > to re-structure some common bits to make the code prettier.
> > >
> > > > My question is that how the addition and narrowing should be performed
> > > > (is it ok to use do_add for addition?).
> > >
> > > I don't see a reason why it would not be.
> > >
> > > > As functions in real.c does
> > > > not operate on any specific precision, just defining the return type
> > > > as float would do the trick? Or do I need to make trailing
> > > > out-of-precision bits zero? If yes, having functions like
> > > > double_to_float would then be useful or such functions already exist
> > > > to do the conversion?
> > >
> > > I am not sure I understand your question, you have used real_convert in
> > > real_fadd and it seems to be doing exactly that?  As you know I am not
> > > too familiar with this area of gcc but reading the code suggests that
> > > and a simple debugging session seems to confirm that (some unimportant
> > > gdb output omitted):
> > >
> > > --
> > > $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
> > > GNU gdb (GDB; openSUSE Tumbleweed) 8.3
> > > Copyright (C) 2019 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later 
> > > 

Supply Chain Managers Contacts

[Linda Hitchcock]

Hi,

I would like to know if you are interested in acquiring contacts list of
Supply Chain Managers for your sales and marketing campaigns.

 

We can also provide verified contacts of: Logistics Managers, Warehouse
Managers, Manufacturing Companies and more.

Let me know your thoughts and target geography, so that I can get back to
you with counts and pricing details for your review.

Thanks and I look forward to hearing from you soon!

Regards,

Linda Hitchcock 

Demand Generation Manager

If you are not interested in receiving our mails reply in subject line leave
out or remove.

 

 

Nota Fiscal Emitida: - 1PG1NI80CDEQ035

[NFe Departamento Fiscal-046]

Autorizado o uso da NF-e



NF-e 
658373571255998

Número do documento: 0483478932

Data de Autorização: 07/08/2019

Chave de Acesso: 0948234974809390823582028342957954859405834803842

KAR4KKN5D1DE63LTNZKM