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
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?
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: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
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
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
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
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
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
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 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: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 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 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-
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 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
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 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 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 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 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 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.
>
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
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
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,
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 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
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
28 matches
Mail list logo
