Snapshot gcc-10-20220107 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20220107/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
> On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote:
>
> Hi Folks,
>
> In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
> the calling convention.
>
> When an argument is passed *in a register* and it is integral and less than
> SI it is promoted (with appropriate s
Hi Folks,
In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of
the calling convention.
When an argument is passed *in a register* and it is integral and less than SI
it is promoted (with appropriate signedness) to SI. This applies when the
function parm is named only.
On 1/7/22 21:14, cert+donotreply--- via Gcc wrote:
Topic 2: There's no such thing as free software, or, how to invest in OSS
security.
Wasn't this Cygnus motto: "We make free software affordable ?"
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14,
We invite you to join us for the CERT Vendor Meeting 2022. This will be a
virtual event, 2022-02-07 10:00-14:30 EST, via Zoom Webinar.
We'll be discussing two topics in some depth, using an extended panel format
(short presentations, moderated discussion, open discussion).
Topic 1: Log4j, a mul
Thanks for the help, that's exactly it!
Andras
On Thu, 2022-01-06 at 20:25 -0800, Andrew Pinski wrote:
> On Thu, Jan 6, 2022 at 8:13 PM Andras Tantos > wrote:
> > Hello!
> >
> > My name is Andras Tantos and I just joined this list, so if I'm
> > asking
> > something off-topic or not following t
On Fri, Jan 07, 2022 at 03:33:54PM -0300, Alexandre Oliva via Gcc wrote:
> On Jan 7, 2022, Martin Jambor wrote:
>
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> I wouldn't mind that.
>
On Jan 7, 2022, Martin Jambor wrote:
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
I wouldn't mind that.
> (Any important caveats I might have missed?)
Having recently renamed a .c source to
On Thu, 2022-01-06 at 17:20 +0100, Martin Jambor wrote:
> Hello,
>
> another year is upon us and Google has announced there will be again
> Google Summer of Code 2022 (though AFAIK there is no specific timeline
> yet). I'd like to volunteer to be the main Org Admin for GCC again so
> let me know
On Fri, 7 Jan 2022 at 16:00, David Malcolm wrote:
> Presumably the generated files should also change from .c to .cc (e.g.
> gengtype generates a gtype-desc.c which is actually C++).
We could do that separately (and right away), couldn't we? That could
even have been done back in the subversion da
On Fri, 2022-01-07 at 11:25 +0100, Martin Jambor wrote:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc
> suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and
On 1/7/2022 7:49 AM, Jeff Law wrote:
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
s
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count tho
Good Day,
I would like to know if you are interested in reaching out to Stackpath?.
We specialize in the Tech information database. If you prefer any other Tech
information database, we can assist. Our data assists businesses like yours to
connect potential customers through email, phone or dir
> On 7 Jan 2022, at 12:55, Martin Liška wrote:
>
> On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
>> References to .cc files in the commit message won't get changed to .c
>> automatically, but maybe the gcc-backport alias could be taught to do
>> that.
> +1 for me. I'm willing to extend gcc-
On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
References to .cc files in the commit message won't get changed to .c
automatically, but maybe the gcc-backport alias could be taught to do
that.
Hi.
+1 for me. I'm willing to extend gcc-backport script to support renaming
files in the commit mes
On Fri, 7 Jan 2022 at 10:54, Jakub Jelinek via Gcc wrote:
> My big worry would be backporting for the next 2 years.
> Do we need to adjust commit messages when backporting to replace *.cc with
> *.c in there? Does git cherry-pick handle the changed files or do we
> need to resolve conflicts manua
On Fri, Jan 07, 2022 at 11:25:50AM +0100, Martin Jambor wrote:
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160
On Fri, 7 Jan 2022 at 10:26, Martin Jambor wrote:
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.
Yes, and it affects tooling like syntax highligh
On Fri, Jan 7, 2022 at 2:35 AM Richard Sandiford via Gcc
wrote:
>
> Martin Jambor writes:
> > Hi,
> >
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> >
> > We already have 47 files with suffi
Martin Jambor writes:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we also count those in (non-t
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while the
Gabriel,
Yes, indeed, thank you.
Note, it is a reminder to those that are receiving proprietary
and that is considered as a legal obligation on the part of the
company transmitting it because they must make an effort to
protect their proprietary information.
I'm not a lawyer either but I feel li
On 1/7/22 09:38, Martin Liška wrote:
On 1/7/22 09:30, Gary Oblock wrote:
Regarding the corporate legal gibberish. It's automatic
and not under my control also we're not supposed to
use private emails for work...
I respect that. But please respect me that I won't reply to your
emails any longer
On 1/7/22 09:30, Gary Oblock wrote:
Regarding the corporate legal gibberish. It's automatic
and not under my control also we're not supposed to
use private emails for work...
I respect that. But please respect me that I won't reply to your
emails any longer. I don't want to follow the condition
Martin,
Regarding the corporate legal gibberish. It's automatic
and not under my control also we're not supposed to
use private emails for work...
Gary
From: Martin Liška
Sent: Friday, January 7, 2022 12:20 AM
To: Gary Oblock ; gcc@gcc.gnu.org
Subject: Re: Issue
On 1/7/22 09:10, Gary Oblock via Gcc wrote:
An optimization flag that I recently added is being
set to zero in push_cfun (which after a couple of
levels of calls cl_optimization_restore to this.)
Question is: what's the value of the flag in your IPA pass
if you set -finterleaving-index-32-bits?
An optimization flag that I recently added is being
set to zero in push_cfun (which after a couple of
levels of calls cl_optimization_restore to this.)
The flag defined like this:
finterleaving-index-32-bits
Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
Structure reorganization
28 matches
Mail list logo
