Re: Need for __builtin_issignaling()

[Joseph Myers]

On Wed, 29 Dec 2021, FX via Gcc wrote:

> Is it particularly hard to do? I came across a post in the list archives 
> from Joseph, who said it would be good to have. I’d be willing to try 
> and put something together, unless you think it’s a big project. Any 
> pointers as to how to start would be appreciated.

Start by looking at Tamar Christina's patch for bugs 77925, 77926, 66462, 
which got reverted because of problems it caused.  In particular, see my 
comment 18 in bug 66462 pointing to some of the reports of issues, and 
look at the relevant discussion in June 2017.  I think the following 
comment 19 is incorrect (when it refers to June and November, those are 
June 2017 and November 2016, so the November version is an *older* one, 
but that comments is under the apprehension that it was a newer one).

There's no need to use that patch as a starting point, but it may well be 
helpful to do so, or at least to get ideas from it.  It didn't add 
__builtin_issignaling, but did add implementations of other related 
built-in functions based on bit-manipulation, and __builtin_issignaling 
would need to be implemented based on such bit-manipulation.

Apart from avoiding the bugs in that patch, for __builtin_issignaling 
there isn't any other implementation approach to fall back on, and there 
isn't any defined external-linkage function to fall back on either.  So 
it's strongly desirable to have a built-in function that works (is 
expanded inline) for *all* floating-point formats supported by GCC, not 
just some.  (For formats not supporting signaling NaNs, it can trivially 
return 0 after evaluating the argument for its side effects.)  Note that 
supporting all formats includes working for formats where integer 
arithmetic on a same-size integer isn't supported (TFmode on 32-bit 
architectures where there isn't TImode integer arithmetic, in particular), 
so you need to be careful about working correctly in that case.

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

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

[Joseph Myers]

On Mon, 28 Mar 2022, Harald Anlauf via Gcc-patches wrote:

> Hi Tobias,
> 
> sorry for replying to myself now, but
> 
> Am 28.03.22 um 22:03 schrieb Harald Anlauf via Fortran:
> > All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
> > 'sprintf', and I did not find any other use of %wd/%wu.  So the
> > mentioned implementation is not really stressed yet... ;-)
> 
> using HOST_WIDE_INT_PRINT_DEC in the format argument to gfc_error
> instead of using %wd does not produce a warning and works.
> (Also verified with insane character lengths on x86_64).

Using string concatenation with a macro is not appropriate in a message 
argument to a diagnostic function, because it means the full string (which 
has to be host-independent) doesn't get extracted for translation.

HOST_WIDE_INT_PRINT_* are printf formats for the host printf function (for 
example, they might use %I64d on Windows host), and are not generally 
understood by the diagnostic.cc machinery at all; functions using the GCC 
diagnostic machinery need to use GCC diagnostic formats (which are 
independent of the host printf function), such as %wd/%wu.

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

Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+

[Joseph Myers]

On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote:

> On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> > I don’t like the _Float128 vs __float128 business, it’s confusing.
> > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> > they seem to be basically the same thing, so it’s also redundant.
> 
> I thought __float128 and _Float128 are distinct and incompatible in the FEs
> and equivalent in middle-end and back-end, but apparently they are
> considered equivalent even for _Generic.

Yes, when both are supported, they are the same type.  The main 
differences (not relevant for this patch, I think) are:

* _Float128 is supported on systems where long double has the IEEE 
binary128 format (as a distinct type from long double even when they have 
the same format); __float128 generally isn't supported on such systems.

* __float128 is supported in C++, _Float128 isn't (though we've discussed 
adding support for _FloatN type names and corresponding fN constant 
suffixes in C++; see the thread on the gcc list in March 2021).

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, FX via Gcc wrote:

> 1. Is this list normative, and was it modified later (I have only found 
> a 2012 draft)?

See N3047 Annex F for the current bindings (there have been a lot of 
changes to the C2x working draft after N3047 in the course of editorial 
review, but I don't think any of them affect the IEEE bindings for 
comparisons).

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, FX via Gcc wrote:

> A tentative patch is attached, it seems to work well on simple examples, 
> but for test coverage the hard part is going to be that the comparisons 
> seem to be optimised away very easily into their non-signaling versions. 
> Basically, if I do:

Presumably that can be reproduced without depending on the new built-in 
function?  In which case it's an existing bug somewhere in the optimizers.

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, Marc Glisse via Gcc wrote:

> On Thu, 1 Sep 2022, Joseph Myers wrote:
> 
> > On Thu, 1 Sep 2022, FX via Gcc wrote:
> > 
> > > A tentative patch is attached, it seems to work well on simple examples,
> > > but for test coverage the hard part is going to be that the comparisons
> > > seem to be optimised away very easily into their non-signaling versions.
> > > Basically, if I do:
> > 
> > Presumably that can be reproduced without depending on the new built-in
> > function?  In which case it's an existing bug somewhere in the optimizers.
> 
>  (simplify
>   (cmp @0 REAL_CST@1)
> [...]
>(if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
> && !tree_expr_signaling_nan_p (@1)
> && !tree_expr_maybe_signaling_nan_p (@0))
> { constant_boolean_node (cmp == NE_EXPR, type); })
> 
> only tries to preserve a comparison with sNaN, but not with qNaN. There are

So that needs to take more care about what comparison operations are 
involved.  Since such an optimization is fine for quiet comparisons such 
as ==, != or isless, but not for signaling comparisons such as < <= > >= 
(subject to any question of splitting up -ftrapping-math into more 
fine-grained options allowing different transformations).

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, FX via Gcc wrote:

> Do you want me to file a bug report?

Yes.

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, FX via Gcc wrote:

> I have a Fortran patch ready to submit, but before I do so I’d like to 
> know: do you support or oppose a __builtin_iseqsig()?

I support having such a built-in function.

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

Re: Floating-point comparisons in the middle-end

[Joseph Myers]

On Thu, 1 Sep 2022, FX via Gcc wrote:

> The next thing I need to tackle for Fortran is the implementation of 
> functions that perform maxNum, maxNumMag, minNum, and minNumMag. Am I 
> correct in assuming that maxNum and minNum correspond to fmin and fmax? 

Yes (note that maxNum and minNum were removed in IEEE 754-2019, but 
they're still what fmax and fmin correspond to; the new minimum / maximum 
operations in IEEE 754-2019 are provided by new functions in C2x).

> Are there builtins for maxNumMag and minNumMag? Or does anyone know what 
> the “canonical” way to perform it is? I do not want to mess up corners 
> cases, which is so easy to do…

TS 18661-1 defined functions fmaxmag and fminmag for those; we don't have 
built-in functions for them, and C2x does not include those functions 
given that those operations were also removed in IEEE 754-2019.

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

Re: [PATCH 1/5] c: Set the locus of the function result decl

[Joseph Myers]

On Sun, 13 Nov 2022, Bernhard Reutner-Fischer via Gcc-patches wrote:

> Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
> Ok for trunk?
> 
> Cc: Joseph Myers 
> ---
> gcc/c/ChangeLog:
> 
>   * c-decl.cc (start_function): Set the result decl source
>   location to the location of the typespec.

OK.

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

Re: [ping] driver: Forward '-lgfortran', '-lm' to offloading compilation

[Joseph Myers]

On Tue, 13 Jun 2023, Thomas Schwinge wrote:

> Hi!
> 
> On 2023-06-05T14:25:18+0200, I wrote:
> > OK to push the attached
> > "driver: Forward '-lgfortran', '-lm' to offloading compilation"?
> > (We didn't have a PR open for that, or did we?)
> 
> Ping.

OK.

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

Re: [Patch] OpenMP: Add iterator support to Fortran's depend; add affinity clause

[Joseph Myers]

On Thu, 27 May 2021, Tobias Burnus wrote:

> @Joseph: I CC'ed you in case you have comments regarding
> c-parser.c's c_parser_check_balanced_raw_token_sequence (comment update)
> and c_parser_check_tight_balanced_raw_token_sequence (new); the latter
> is essentially cp_parser_skip_balanced_tokens with slight adaptions.

I don't understand why the name says either "tight" or "balanced".  As far 
as I can see, c_parser_check_tight_balanced_raw_token_sequence isn't 
checking for balanced token sequences (in the sense defined in C2x) at all 
and would accept e.g. }]{[ as being balanced.  Is that really what's 
supposed to be accepted there?  If it is, the comment on the function 
definition needs to explain the exact definition of what token sequences 
are accepted.

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

Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

[Joseph Myers]

On Sun, 5 Sep 2021, Sandra Loosemore wrote:

> Unless the aarch64 maintainers think it is a bug that __float128 is not
> supported, I think the right solution here is the one I was thinking of
> previously, to fix the Fortran front end to tie the C_FLOAT128 kind to
> _Float128 rather than __float128, and fix the runtime support and test cases
> accordingly.  Then there should be no need to depend on quadmath.h at all.
> C_FLOAT128 is a GNU extension and _Float128 is supported on a superset of
> targets that __float128 is, so there should be no issue with backward
> compatibility.

gfc_build_intrinsic_lib_fndecls (at least) knows about the "q" function 
naming in libquadmath, and I think will result in gfortran generating 
calls to *q functions in some cases.


I think there are at least three cases involved:


(a) long double has the IEEE binary128 format.  In that case, the *l 
functions from libm can be used, with no need for libquadmath to be 
involved at all.  (It's still necessary to allow for the long double libm 
functions possibly having a different assembler name, for the powerpc64le 
case, but if the front end goes via built-in functions then it may not 
need further code to handle that specifically; see 
rs6000_mangle_decl_assembler_name.)


(b) long double does not have the IEEE binary128 format, but glibc 
includes support for _Float128 functions (*f128) in libm for this target.  
Whether that support is included depends on the architecture and glibc 
version (glibc 2.26 or later needed; supported for 
x86_64/x86/ia64/powerpc64le).  If the glibc support is present (could be 
tested using GCC_GLIBC_VERSION_GTE_IFELSE in configure to work properly 
when bootstrapping a cross compiler), it would make sense for the Fortran 
front end to use *f128 functions directly and so not depend on 
libquadmath.  But I don't think the Fortran front end actually has any 
support for using *f128 functions at present.

It's possible some non-glibc libraries also support *f128 or will do so in 
future (those are the standard names in TS 18661-3 / C23).  However, you 
can't do configure tests of compiling/linking with target libraries when 
configuring front ends, only grep headers or use information about the 
configured target triplet or configure options (which is more or less what 
GCC_GLIBC_VERSION_GTE_IFELSE does), so I don't think there's anything that 
could readily be done to allow using *f128 from non-glibc libm 
automatically if such libm gains support for those functions in future.


(c) __float128 is supported, different format from long double, but glibc 
does not have _Float128 functions (too old) or a non-glibc libm is in use.  
This is the only case where libquadmath is actually relevant.

(libquadmath code is based on glibc, with some support 
(update-quadmath.py) for updating parts of that code from glibc sources 
automatically (most of the parts based on glibc libm, but not the string 
conversion parts).  In practice, it's likely that changes to 
update-quadmath.py would be needed as part of such an update.)


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

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

[Joseph Myers]

On Tue, 14 Sep 2021, Andreas Schwab wrote:

> On Sep 14 2021, Jakub Jelinek wrote:
> 
> > But, wonder why it didn't work with the float.h include then, because
> > https://github.com/lattera/freebsd/blob/master/sys/x86/include/float.h
> > seems to define LDBL_MANT_DIG to 64, LDBL_MIN_EXP to (-16381) and
> > LDBL_MAX_EXP to 16384 and that case was handled in ISO_Fortran_binding.h.
> 
> Doesn't gcc always use its own float.h?

Subject to USER_H (i.e., except on OpenBSD, where GCC tests for newer 
float.h features would probably fail unless OpenBSD's version exactly 
matches the GCC testsuite expectations for those features).

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Mon, 4 Oct 2021, Jakub Jelinek via Gcc wrote:

> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines.  Perhaps
> convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
> of precision and range, but at least something).

Using libquadmath functions would be better in that case - arranging for 
libquadmath to be built in this case if it isn't already - than converting 
to __ibm128.

(On the other hand, when _Float128 functions are available in libm, I 
think it would be better for Fortran to call those rather than libquadmath 
functions - *f128 (or the __*ieee128 aliases available on powerpc64le for 
namespace reasons, not sure if those namespace reasons have any relevance 
to Fortran) instead of *q.  See my comments on that in 
.)

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Mon, 4 Oct 2021, Segher Boessenkool wrote:

> Some current Power GCC targets support neither.  Some support only
> double-double.  Making IEEE QP float work on those (that is, those that
> are < power8) will require some work still: it should use libquadmath or
> similar, but that needs to be put into the ABIs, to define how parameter
> passing works for those types.  Just treating it like a struct or an
> array of ints will work fine, but it needs to be written down.  This is
> more than just Fortran.

Is the 64-bit BE (ELFv1) ABI maintained somewhere?  (The 32-bit ABI, 
covering both hard float and soft float, is 
 - no activity lately, but I think 
Ryan said he'd given write access to someone still involved with Power.)

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:

> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example).  This can
> > magically make -msoft-float work as well everywhere, btw.
> 
> Emulation is one thing, but another one is where are those __float128 or
> quad long double arguments and return values passed.  On power8 le I think
> they are passed in VSX registers, aren't they?
> But are those available everywhere where ppc64 is supported?  For ppc32
> certainly not, I don't remember for ppc64.

As noted in previous discussions, while the current GCC implementation 
requires VSX for _Float128 support, the registers used in the ABI are the 
same as AltiVec registers; it would be possible to implement support for 
_Float128 on all powerpc64 with AltiVec (most but not all 64-bit 
processors), using AltiVec registers in the ABI and being fully compatible 
with the ABI using VSX registers.

> Sure, the ABI could say pass it in e.g. in a pair of integer registers...

You'd need to decide whether you want the 64-bit BE ABI for _Float128 to 
be one that supports the type on all 64-bit processors (so pass in integer 
registers), or one that only supports it on processors with AltiVec but is 
more similar to the LE ABI (passing in AltiVec registers).

And, then, decide the 32-bit ABIs (hard and soft float), if you want to 
support _Float128 there.

And, then, do glibc changes, both to support _Float128 functions at all, 
and to support a different long double format if you wish to support 
changing the long double format for those ABIs.  Note that the symbol 
versioning in glibc assumes that all libm functions either predate 
_Float128 support on all architectures (version of *f128 versions is 
FLOAT128_VERSION) or postdate it on all architectures (versions in 
math/Versions based on whenever that function was added to glibc; various 
*f64x functions, that alias *f128 when appropriate, are also hardcoded as 
GLIBC_2.27).  So if someone adds _Float128 support to any glibc ABI that 
doesn't currently have it, they need to add support for new syntax in 
Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes 
the right symbol version for a _Float128 function added in 2.28, in the 
case where some architecture gets _Float128 support later than that.  And 
likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add 
support for it being used as a new long double format.  And adding the 
support to glibc means increasing the minimum GCC version for building 
glibc for those ABIs to one that supports _Float128 for those ABIs.

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> Soft float is not described in any formal ABI btw (well, except the
> Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.

It's fully documented in the unified 32-bit ABI document (under 
ATR-SOFT-FLOAT conditionals).

There's still some code in the compiler for a very old soft-float ABI for 
binary128 long double (passing by reference, using _q_* libcall names).  I 
don't really think it makes much sense to use that for future _Float128 
support for soft-float (certainly not the _q_* libcalls), rather than 
passing in four consecutive GPRs as is done for IBM long double for soft 
float, but we could.

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> > There's still some code in the compiler for a very old soft-float ABI for 
> > binary128 long double (passing by reference, using _q_* libcall names).  I 
> > don't really think it makes much sense to use that for future _Float128 
> > support for soft-float (certainly not the _q_* libcalls), rather than 
> > passing in four consecutive GPRs as is done for IBM long double for soft 
> > float, but we could.
> 
> Maybe this harks back to POWER2 days?  If so, we probably should just
> remove that code, we do not support anything else POWER2 anymore.

The _q_* names and associated ABI are in the 1995 SunSoft PowerPC ABI 
(which I suppose was the ABI for PowerPC Solaris).

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Wed, 6 Oct 2021, Segher Boessenkool wrote:

> With "not in any" I mean: not for other architectures either!  All archs
> that do not say anything about floating point in their machine
> description get a working sofware floating point (for binary32 and
> binary64 currently).

Any architecture that supports a software floating-point ABI (i.e. one 
that does argument passing and return for floating-point in integer 
registers) should specify it in its ABI documents.  For example, 
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc 
describes both "Integer Calling Convention" and "Hardware Floating-point 
Calling Convention", with a series of named ABIs based on those such as 
LP64, LP64F, etc. (like on (32-bit) Arm, but unlike Power or MIPS, RISC-V 
GCC also supports building programs that use hardware floating-point 
instructions but the software floating-point ABI).

That's how the (unified) 32-bit powerpc ABI documents things: both 
hardware and software floating-point ABI variants.

If the architecture doesn't support hardware floating point, or doesn't 
have separate registers for it, the software floating-point ABI is just 
"the ABI" and there's no separate hardware floating-point ABI, of course.

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Fri, 8 Oct 2021, Segher Boessenkool wrote:

> But many CPUs do not have hardware floating point in any variant, and
> their ABIs / calling conventions do not mention floating point at all.
> Still, this works with GCC just fine: it passes floats and doubles the
> same as 32-bit resp. 64-bit integers.
> 
> binary16 and bfloat16 would be easy to support the same way, but it is a
> bit harder for binary128, because we do not have a 128-bit integer type

Supporting passing arguments (and return values) the same as an integer 
type of the same size is a *choice* (which comes with other choices - in 
particular, whether to say some or all the higher bits in the register or 
stack slot are sign-extended, zero-extended or undefined).  It's a choice 
that should be made explicitly, and documented (in the relevant ABI if one 
is maintained), and coordinated between implementations when there's more 
than one implementation for the architecture trying to be compatible.  
We've had plenty of problems in the past with ABIs that were just what 
happened to fall out of the implementation (e.g. ABIs that depended on the 
details of what machine mode was assigned to a structure type...).

On a related note, I'd encourage architecture maintainers to start 
thinking now about what exactly their ABIs should be for _BitInt 
(, accepted as 
a required feature for C23 up to at least the width of unsigned long 
long), and documenting it and coordinating with other implementations 
where appropriate.  There's a concrete proposal for x86_64 (see 
origin/usr/hjl/bitint branch at 
https://gitlab.com/x86-psABIs/x86-64-ABI.git) that may at least help as an 
indication of the sort of issues to address in such an ABI.

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

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote:

> Beyond ABI and compiler support, glibc would also need to support IEEE 
> QP for these other targets.  Currently we only have support for 
> powerpc64le.

And that would involve new syntax in glibc Versions files, as discussed in 
, to give the 
binary128 versions of certain functions (functions added after the initial 
_Float128 support was added to glibc but before it gets added for these 
other ABIs) the right symbol version.

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

Re: On pull request workflows for the GNU toolchain

[Joseph Myers]

On Mon, 23 Sep 2024, enh via Gcc wrote:

> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use the mailing list otherwise ... taking into
> account that what the "barriers" are depend on whose eye's you're looking
> through.

My expectation is that such a split would need to work for an initial 
transitional period at least (for reviews of patches posted before the 
move to the forge software without requiring all such under-review patches 
to go into PRs if people want review, if nothing else).  While I think 
there are advantages in terms of structured data if everything ends up 
using PRs (including people doing PRs that are immediately self-merged of 
changes in areas they maintain), it would be possible to do otherwise (at 
least until you get to wanting all merges to mainline to be done by a CI 
system that maintains a regression-free state for at least one 
configuration).

-- 
Joseph S. Myers
josmy...@redhat.com

Re: *PING* [PATCH v3 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]

[Joseph Myers]

On Fri, 13 Sep 2024, Mikael Morin wrote:

> *PING*
> 
> Joseph, could you take a quick look at the handling of the new option?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html

Individual new options like this are expected to be reviewed by 
maintainers / reviewers for the relevant part of the compiler, not for 
option handling which is more for the generic machinery independent of 
individual options.

-- 
Joseph S. Myers
josmy...@redhat.com