Snapshot gcc-11-20220617 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20220617/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Fri, 2022-06-17 at 22:23 +0200, Tim Lange wrote:
> On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
[...snip...]
> >
>
> I have resent the patch using git send-email as a reply to my original
> message.
> The new message
On Fri, 2022-06-17 at 21:23 +0200, Tim Lange wrote:
>
>
> On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni
> wrote:
> > On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote:
> > >
> > > Hi everyone,
> > Hi Tim,
> > Thanks for posting the POC patch!
> > Just a couple of comments (inline)
>
On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
> > Hi everyone,
>
> Hi Tim.
>
> Thanks for the patch.
>
> Various comments inline below, throughout...
>
> >
> > tracked in PR105900 [0], I'd like to add support for a new warn
On Fri, 17 Jun 2022 at 19:45, Bernhard Reutner-Fischer wrote:
>
> On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran
> wrote:
>
> >https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh
>
> s/[[/[/
> s/==/=/
>
> The former are deprecated or obsolescent
On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc
wrote:
> PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
No. gcc_build is used by maintainer-scripts/gcc_release, so by killing it
you'd make gcc unreleasable.
> It was not updated since th
On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni
wrote:
On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote:
Hi everyone,
Hi Tim,
Thanks for posting the POC patch!
Just a couple of comments (inline)
Hi Prathamesh,
thanks for looking at it.
tracked in PR105900 [0], I'd like to add
On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran
wrote:
>https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh
s/[[/[/
s/==/=/
The former are deprecated or obsolescent notations of test(1) syntax, fwiw.
PS: we should rm https://gcc.gnu.org/git/?
I think my mail client did apply auto-wrap and reduced multiple spaces to a
single one while doing so. Here again, the full patch as well as the ASCII
diagnostics. This should look better now.
On constant size allocations:
/path/to/allocation-size-3.c:22:14: warning: Allocated buffer size is not
On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
> Hi everyone,
Hi Tim.
Thanks for the patch.
Various comments inline below, throughout...
>
> tracked in PR105900 [0], I'd like to add support for a new warning on
> dubious allocation sizes. The new checker emits a warning when the
> alloca
On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote:
>
> Hi everyone,
Hi Tim,
Thanks for posting the POC patch!
Just a couple of comments (inline)
>
> tracked in PR105900 [0], I'd like to add support for a new warning on
> dubious allocation sizes. The new checker emits a warning when the
> allocation s
> On Jun 17, 2022, at 11:51 AM, Andreas Schwab wrote:
>
> On Jun 17 2022, Paul Koning via Gcc wrote:
>
>> In expanding a longer-than-word compare, I need to do things differently
>> depending on whether a signed vs. unsigned compare is needed. But it seems
>> the compare operation applies
Hi everyone,
tracked in PR105900 [0], I'd like to add support for a new warning on
dubious allocation sizes. The new checker emits a warning when the
allocation size is not a multiple of the type's size. With the checker,
following mistakes are detected:
int *arr = malloc(3); // forgot to mu
On Jun 17 2022, Paul Koning via Gcc wrote:
> In expanding a longer-than-word compare, I need to do things differently
> depending on whether a signed vs. unsigned compare is needed. But it seems
> the compare operation applies to either. How can I do this in the target
> code?
There are both
Question for target code:
In expanding a longer-than-word compare, I need to do things differently
depending on whether a signed vs. unsigned compare is needed. But it seems the
compare operation applies to either. How can I do this in the target code?
paul
15 matches
Mail list logo
