On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote:
> On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> > The last release (version 1.9) was in 2004. If there is interest in
> > making updates to it that coulde be done of course, it is GFDL, there is
> > no red tape getting in the way.
>
Hi!
On Mon, Oct 11, 2021 at 08:11:50PM +, Joseph Myers wrote:
> 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
Snapshot gcc-9-20211014 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20211014/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> Hi Joseph,
>
> On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote:
>> 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 th
Am Donnerstag, dem 14.10.2021 um 13:17 + schrieb Michael Matz:
> Hello,
>
> On Wed, 13 Oct 2021, Martin Uecker wrote:
>
> > > [... static chain ...]
> > > If you mean that, then it's indeed psABI specific, and possibly
> > > not
> > > al ABIs specify it (in which case GCC will probably have s
Hi.
In certain places, the i370 target of GCC 3.2.3 will use a
base + index + displacement operand.
How can I add a constraint to say that the index must be
between 0 and 0x7fff?
I want to stop 0x from being generated when I have:
char *p
p[-1];
Thanks. Paul.
--
This email has be
Hello,
On Wed, 13 Oct 2021, Martin Uecker wrote:
> > [... static chain ...]
> > If you mean that, then it's indeed psABI specific, and possibly not
> > al ABIs specify it (in which case GCC will probably have set a de-
> > facto standard at least for unixy systems). The x86-64 psABI for
> > inst
On Wed, Oct 13, 2021 at 7:54 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> My current understanding of LTO is that the callgraph is very dynamic
> (i.e., optimizations might add or remove cgraph_nodes). A while back I
> encountered an issue where I couldn't print the cgraph_node::name of a
> function
