gcc-10-20220107 is now available

[GCC Administrator via Gcc]

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 
releases/gcc-10 revision 6a3018a4064b39a418d95c32e45fe7d6ad17ebf3

You'll find:

 gcc-10-20220107.tar.xz   Complete GCC

  SHA256=06bff2b3d659d52bf5080ca86bf0d77b058867d82002bb902a9688b90a7d34ac
  SHA1=ac0b991ef705cec04aff386269fa0ab1cbd279f5

Diffs from 10-20211231 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Help with an ABI peculiarity

[Paul Koning via Gcc]

> 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 signedness) to SI.  This applies when the 
> function parm is named only.
> 
> When the same argument would be placed on the stack (i.e. we ran out of 
> registers) - it occupies its natural size, and is naturally aligned (so, for 
> instance, 3 QI values could be passed as 3 registers - promoted to SI .. or 
> packed into three adjacent bytes on the stack)..
> 
> The key is that we need to know that the argument will be placed in a 
> register before we decide whether to promote it.
> (similarly, the promotion is not done in the callee for the in-register case).
> 
> I am trying to figure out where to implement this.

I don't remember the MIPS machinery well enough, but is that a similar case?  
It too has register arguments (4 or 8 of them) along with stack arguments (for 
the rest).

paul

Help with an ABI peculiarity

[Iain Sandoe]

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.

When the same argument would be placed on the stack (i.e. we ran out of 
registers) - it occupies its natural size, and is naturally aligned (so, for 
instance, 3 QI values could be passed as 3 registers - promoted to SI .. or 
packed into three adjacent bytes on the stack)..

The key is that we need to know that the argument will be placed in a register 
before we decide whether to promote it.
(similarly, the promotion is not done in the callee for the in-register case).

I am trying to figure out where to implement this.

* the code that (in regular cases) decides on such promotions is called 
_before_ we call target’s function_arg.

* OVERRIDE_ABI_FORMAT seems to be called too early (we don’t have enough 
information on the function - to decide to set the PARM passed-as type).

I’ve experimented with various schemes - specifically that  tm.function_arg can 
alter the mode of the register in the appropriate cases, and then calls.c can 
act on the case that the mode has been changed by that callback.

It seems probable that this approach can be made non-invasive - but...
... if someone can point me at a better solution - I’m interested.

thanks
Iain

Re: [gen-14164] Invitation to the CERT Vendor Meeting 2022

[Toon Moene]

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, 3738 XG  Maartensdijk, The Netherlands

[gen-14164] Invitation to the CERT Vendor Meeting 2022

[cert+donotreply--- via Gcc]

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 multi-party coordinated vulnerability disclosure failure?

Topic 2: There's no such thing as free software, or, how to invest in OSS 
security.

Registration: 

Questions: 




This e-mail was sent to you as a user of our VINCE service, in accordance with 
our privacy policy. Please advise us if you believe you have received this 
e-mail in error.

Re: Why doesn't this pattern match?

[Andras Tantos]

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 the rules of the community,
> > please
> > let me know.
> > 
> > What I'm working on is to port GCC (and Binutils) to a new CPU ISA,
> > I
> > call 'brew'. During developing for this target, I got the following
> > error:
> 
> How are the following constraints defined:
> W,A,B
> 
> Does one include the pc register?
> Otherwise you have a mismatch between the predicate
> brew_general_mov_src_operand (which accepts the pc register) and the
> constraint which does not.
> 
> Thanks,
> Andrew Pinski
> 
> 
> > first.c: In function ‘test_call’:
> > first.c:61:52: error: insn does not satisfy its constraints:
> >61 | int test_call(int a, int b) { return test_qm(a,b); }
> >   |^
> > (insn 25 8 9 (set (reg:SI 6 $r6)
> > (reg:SI 0 $pc)) "first.c":61:38 17 {*movsi}
> >  (nil))
> > during RTL pass: final
> > first.c:61:52: internal compiler error: in final_scan_insn_1, at
> > final.c:2811
> > 0x6c4c23 _fatal_insn(char const*, rtx_def const*, char const*, int,
> > char const*)
> > ../../brew-gcc/gcc/rtl-error.c:108
> > 0x6c4c4f _fatal_insn_not_found(rtx_def const*, char const*, int,
> > char
> > const*)
> > ../../brew-gcc/gcc/rtl-error.c:118
> > 0x643585 final_scan_insn_1
> > ../../brew-gcc/gcc/final.c:2811
> > 0xb1ef3f final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
> > ../../brew-gcc/gcc/final.c:2940
> > 0xb1f207 final_1
> > ../../brew-gcc/gcc/final.c:1997
> > 0xb1fbe6 rest_of_handle_final
> > ../../brew-gcc/gcc/final.c:4285
> > 0xb1fbe6 execute
> > ../../brew-gcc/gcc/final.c:4363
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > 
> > 
> > Clearly, the compiler couldn't find a rule that works for this
> > register
> > move. The relevant section of the .md file is:
> > 
> > (define_expand "movsi"
> >[(set (match_operand:SI 0 "general_operand" "")
> >  (match_operand:SI 1 "general_operand" ""))]
> >""
> >   "
> > {
> >   /* If this is a store, force the value into a register.  */
> >   if (! (reload_in_progress || reload_completed))
> >   {
> > if (MEM_P (operands[0]))
> > {
> >   operands[1] = force_reg (SImode, operands[1]);
> >   if (MEM_P (XEXP (operands[0], 0)))
> > operands[0] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP
> > (operands[0], 0)));
> > }
> > else
> >   if (MEM_P (operands[1])
> >   && MEM_P (XEXP (operands[1], 0)))
> > operands[1] = gen_rtx_MEM (SImode, force_reg (SImode, XEXP
> > (operands[1], 0)));
> >   }
> > }")
> > 
> > (define_insn "*movsi"
> >   [(set (match_operand:SI 0
> > "nonimmediate_operand""=r,r,r,W,A,B,r,r,r")
> > (match_operand:SI 1 "brew_general_mov_src_operand"
> > "O,r,i,r,r,r,W,A,B"))]
> >   "register_operand (operands[0], SImode)
> >|| register_operand (operands[1], SImode)"
> >   "@
> >%0 <- %0 - %0
> >%0 <- %1
> >%0 <- %1
> >mem[%0] <- %1
> >mem[%0] <- %1
> >mem[%0] <- %1
> >%0 <- mem[%1]
> >%0 <- mem[%1]
> >%0 <- mem[%1]"
> > )
> > 
> > 
> > As you can imagine, I'm fairly new to GCC development, so I must be
> > making some rookie mistake here, but I would have thought that the
> > second alternative in the "*movsi" rule above would match the
> > pattern.
> > 
> > brew_general_mov_src_operand is defined as follows:
> > 
> > (define_predicate "brew_general_mov_src_operand"
> >   (match_code
> > "mem,const_int,reg,subreg,symbol_ref,label_ref,const")
> > {
> >   /* Any (MEM LABEL_REF) is OK.  That is a pc-relative load.  */
> >   if (MEM_P (op) && GET_CODE (XEXP (op, 0)) == LABEL_REF)
> > return 1;
> > 
> >   if (MEM_P (op)
> >   && GET_CODE (XEXP (op, 0)) == PLUS
> >   && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG
> >   && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT
> >   )
> > return 1;
> >   /* Any register is good too */
> >   if (REG_P(op))
> > return 1;
> >   /* PC as source is also acceptable */
> >   if (op == pc_rtx)
> > return 1;
> >   return general_operand (op, mode);
> > })
> > 
> > 
> > Thanks for all the help,
> > Andras
> > 
> > 

Re: Mass rename of C++ .c files to .cc suffix?

[Jakub Jelinek via Gcc]

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.
> 
> > (Any important caveats I might have missed?)
> 
> Having recently renamed a .c source to .cc in a development branch, one
> annoying issue that came up was that dependency tracking in build trees
> couldn't recover from the renaming on its own: it kept on insisting that
> the previously-existing .c file was missing, instead of picking up the
> .cc.  This could be a problem for hands-off CI testers, besides the
> slight annoyance of having to wipe out the build tree, or at least hunt
> down and remove dep-tracking files.
> 
> It's no biggie, I'm not sure there's some change to the build machinery
> we could make ahead of time to alleviate this, but it should probably be
> mentioned in the announcement of the change if/when it goes in.

So it will be something to work around in bisection scripts (though sure,
over the years we have various quirks in there), e.g. in the svn era I have
if [ $rev -gt 202892 ]; then [ ! -f .deps/toplev.Po ] && rm -f `ls -1 *.o */*.o 
| grep -v 'crt.*o'`; else [ -d .deps ] && rm -rf .deps */.deps; fi

Jakub

Re: Mass rename of C++ .c files to .cc suffix?

[Alexandre Oliva via Gcc]

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 .cc in a development branch, one
annoying issue that came up was that dependency tracking in build trees
couldn't recover from the renaming on its own: it kept on insisting that
the previously-existing .c file was missing, instead of picking up the
.cc.  This could be a problem for hands-off CI testers, besides the
slight annoyance of having to wipe out the build tree, or at least hunt
down and remove dep-tracking files.

It's no biggie, I'm not sure there's some change to the build machinery
we could make ahead of time to alleviate this, but it should probably be
mentioned in the announcement of the change if/when it goes in.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: GCC GSoC 2022: Call for project ideas and mentors

[David Malcolm via Gcc]

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 if you think I shouldn't or that someone else should, but
> otherwise I'll assume that I will.
> 
> There will be a few important changes to the GSoC this year.  The most
> important for us is that there will be two project sizes: medium-sized
> projects which are expected to take about 175 hours to complete and
> large projects expected to take approximately 350 hours (the size from
> 2020 and earlier).  I expect that most of our projects will be large
> but
> I think we can offer one or two medium-sized ideas too.
> 
> Google will also increase timing flexibility, so the projects can run
> for longer (up to 22 weeks) allowing mentors to go on vacation and
> students to pause and focus on exams.  Talking about students, Google
> is
> going to open the program to all adults, so from now on, the
> participants working on the projects will be called GSoC contributors.
> 
> Slightly more information about these changes can be found at
> https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
> I am sure we will learn more when the actual timeline is announced too.
> 
>  The most important bit:
> 
> 
> Even before that happens, I would like to ask all (moderately) seasoned
> GCC contributors to consider mentoring a student this year and ideally
> also come up with a project that they would like to lead.  I'm
> collecting proposal on our wiki page
> https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
> top list there.  Or, if you are unsure, post your offer and project
> idea
> as a reply here to the mailing list.

How did it get to be 2022 already?

Thanks for organizing this.

I'd like to (again) mentor a project relating to the GCC static
analyzer:
  https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer

I've updated the analyzer task ideas on:
  https://gcc.gnu.org/wiki/SummerOfCode
but the ideas there are suggestions; if any prospective candidate has
other good ideas for things worth working on within the analyzer, let
me know.

Alternatively, I'm also up for mentoring relating to diagnostics or
libgccjit, if someone can think of an idea of suitable size and scope
for a GSoC project.

Dave

> 
> ===
> ==
> 
> Eventually, each listed project idea should have a) a project
> title/description, b) more detailed description of the project (2-5
> sentences), c) expected outcomes, d) skills required/preferred, e)
> project size and difficulty and f) expected mentors.
> 
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with
> yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one.
> 
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
> 
> Finally, please continue helping (prospective) students figure stuff
> out
> about GCC like you always do.  So far I think all of them enjoyed
> working with us, even if many sometimes struggled with GCC's
> complexity.
> 
> I will update you as more details about GSoC 2022 become available.
> 
> Thank you, let's hope we attract some new talent again this year.
> 
> Martin
> 

Re: Mass rename of C++ .c files to .cc suffix?

[Jonathan Wakely via Gcc]

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 days, no?

Re: Mass rename of C++ .c files to .cc suffix?

[David Malcolm via Gcc]

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 160 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still
> has
> the .c suffix.
> 
> 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.
> 
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we
> did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
> 
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
> 
> What do others think?  (Any important caveats I might have missed?)

+1 from me.

Various details:

Presumably the generated files should also change from .c to .cc (e.g.
gengtype generates a gtype-desc.c which is actually C++).

grep for "files_rules" in gengtype: it seems to have some hardcoded
regex patterns that end in "\\.c" (not sure what these do, but should
be investigated w.r.t. a renaming to .cc)

A minor detail that would be nice to get right: the selftests manually
code the names of source files in function names; see
selftest::run_tests in selftest-run-tests.c, which has lots of calls to
functions of the form "foo_c_tests ();"  These function names should
probably be renamed to "foo_cc_tests" if "foo.c" is renamed to
"foo.cc".  Though perhaps that can wait to a followup, or be a separate
commit, if that helps with backporting.

Hope this is constructive
Dave

Re: Mass rename of C++ .c files to .cc suffix?

[Jeff Law via Gcc]

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
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while the majority of our non-header C++ files still has
the .c suffix.

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.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)
I think it's well past time we do this.   There may be a bit of pain 
with cherry-picking across the rename point, but we should just deal 
with it.
 I realized this might be mis-interpreted.  The "well past time" was 
really meant to signal that I think we probably should have made this 
change long ago and that waiting even longer just doesn't make sense to me.


I'm fully in favor and have no objections to making it now.  I wouldn't 
be terribly surprised if it's less intrusive to make now rather than 
after gcc-12 is released.  Making it now affects trunk->gcc11 and 
earlier backports which should be smaller than trunk->gcc-12 backports 
we'd be making in the summer/fall if we were to defer until after gcc-12.


jeff

Re: Mass rename of C++ .c files to .cc suffix?

[Jeff Law via Gcc]

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 those in (non-testsuite)
subdirectories, while the majority of our non-header C++ files still has
the .c suffix.

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.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)
I think it's well past time we do this.   There may be a bit of pain 
with cherry-picking across the rename point, but we should just deal 
with it.


jeff

Stackpath

[Shirley Falk]

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 direct mails.

If yes, please suggest your specifications as samples, counts and cost will be 
sent to your attention.

Thanks and Regards,
Shirley Falk
VP

Note: If you don't want to receive any more emails from us Opt Out

Re: Mass rename of C++ .c files to .cc suffix?

[Iain Sandoe via Gcc]

> 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-backport script to support renaming
> files in the commit messages

+1 for me if the backport workflow is confirmed to be OK (I mainly cherry-
pick manually, so accept i might need to edit the commit-log, or learn to use
the script ;) ).

Iain

Re: Mass rename of C++ .c files to .cc suffix?

[Martin Liška]

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 messages.

Cheers,
Martin

Re: Mass rename of C++ .c files to .cc suffix?

[Jonathan Wakely via Gcc]

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 manually?

git cherry-pick (and the gcc-backport alias) should handle it
automatically, unless the diffs between trunk and the branch are a
large percentage of the whole file. IOf a file has been renamed then
Git finds the file to apply the patch to by comparing file contents
fuzzily. For a large repo like GCC you might want to set the
merge.renameLimit config variable so that it doesn't give up trying to
find the file too early. I did 'git config merge.renameLimit 9001' in
my repos. You can also set it to 0 which uses a hardcoded maximum
decided by Git, which gets updated now and then to ensure it works for
the kernel. That maps to a value much larger than 9000, but I've found
that my GCC cherry picks work with 9001.

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.

Re: Mass rename of C++ .c files to .cc suffix?

[Jakub Jelinek via Gcc]

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 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still has
> the .c suffix.
> 
> 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.
> 
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
> 
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
> 
> What do others think?  (Any important caveats I might have missed?)

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 manually?

Jakub

Re: Mass rename of C++ .c files to .cc suffix?

[Jonathan Wakely via Gcc]

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 highlighting and indenting
rules in editors. I think that's one of the strongest arguments in
favour of renaming them.

Apart from that, I don't have any strong opinion either way (libstdc++
has always used .cc and I rarely touch the rest of the compiler).

Re: Mass rename of C++ .c files to .cc suffix?

[Andrew Pinski via Gcc]

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 suffix .cc directly in the gcc
> > subdirectory and 160 if we also count those in (non-testsuite)
> > subdirectories, while the majority of our non-header C++ files still has
> > the .c suffix.
> >
> > 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.
> >
> > Since we have switched to git, this should have quite small effect on
> > anyone who does their development on branches.  With Martin Liška we did
> > a few experiments and git blame, git rebase and even git gcc-backport
> > worked seamlessly across a rename.
> >
> > I would be fine waiting with it until GCC 12 gets released but see
> > little value in doing so.
> >
> > What do others think?  (Any important caveats I might have missed?)
>
> +1 in favour FWIW.  And I agree we might as well do it now.  It seems
> likely to be less disruptive than waiting to GCC 12, since at that point
> there's going to be more bug fixes that need to be applied to both trunk
> and the new branch, as well as the unleashed stage 1 patches.

+1 in favor. (I don't mind it either time really).
I also think the generated files that get built in the build directory
should also be moved but that is more depth patch.

Thanks,
Andrew Pinski


>
> Thanks,
> Richard

Re: Mass rename of C++ .c files to .cc suffix?

[Richard Sandiford via Gcc]

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-testsuite)
> subdirectories, while the majority of our non-header C++ files still has
> the .c suffix.
>
> 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.
>
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
>
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
>
> What do others think?  (Any important caveats I might have missed?)

+1 in favour FWIW.  And I agree we might as well do it now.  It seems
likely to be less disruptive than waiting to GCC 12, since at that point
there's going to be more bug fixes that need to be applied to both trunk
and the new branch, as well as the unleashed stage 1 patches.

Thanks,
Richard

Mass rename of C++ .c files to .cc suffix?

[Martin Jambor]

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 majority of our non-header C++ files still has
the .c suffix.

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.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)

Martin

Re: Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

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 like I'm being forced to
act like one. 😉

Now, can anybody answer my question?

Sincerely

Gary


From: Gabriel Ravier 
Sent: Friday, January 7, 2022 12:56 AM
To: Martin Liška ; Gary Oblock ; 
gcc@gcc.gnu.org 
Subject: Re: Issue with a flag that I defined getting set to zero

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


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. I don't want to follow the conditions in the NOTICE!
>
> Cheers,
> Martin
>
As far as I know the notice has no legal significance at all (which Gary
should probably point out to his management. Really, pretty much the
only thing the disclaimer will do is that _some_ people _might_ read it
and _some_ of those people _might_ adhere to the terms given there,
which is basically meaningless compared to the general annoyance
resulting from disclaimers being at the end of e-mails everywhere). You
can't just magically establish an agreement that results in a duty of
nondisclosure like this without agreement, and just receiving an email
obviously isn't that.

(although ironically, I guess I should add a disclaimer of my own: I
ain't a lawyer and this isn't legal advice)

Re: Issue with a flag that I defined getting set to zero

[Gabriel Ravier via Gcc]

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. I don't want to follow the conditions in the NOTICE!

Cheers,
Martin

As far as I know the notice has no legal significance at all (which Gary 
should probably point out to his management. Really, pretty much the 
only thing the disclaimer will do is that _some_ people _might_ read it 
and _some_ of those people _might_ adhere to the terms given there, 
which is basically meaningless compared to the general annoyance 
resulting from disclaimers being at the end of e-mails everywhere). You 
can't just magically establish an agreement that results in a duty of 
nondisclosure like this without agreement, and just receiving an email 
obviously isn't that.


(although ironically, I guess I should add a disclaimer of my own: I 
ain't a lawyer and this isn't legal advice)

Re: Issue with a flag that I defined getting set to zero

[Martin Liška]

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 conditions in the NOTICE!

Cheers,
Martin

Re: Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

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 with a flag that I defined getting set to zero

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


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? It should not really be zero.

>
> The flag defined like this:
>
> finterleaving-index-32-bits
> Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
> Structure reorganization optimization, instance interleaving.
>
> Note, I'm working around this but l'd really like
> to not have to do so therefore I'm wondering if somebody
> could explain what's happening and what I'd need
> to do instead?

You defined the flag well.

>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Can you please remove this ugly notice that it's completely misleading? If not, 
I would then
recommend creating a private email.

Martin

Re: Issue with a flag that I defined getting set to zero

[Martin Liška]

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? It should not really be zero.



The flag defined like this:

finterleaving-index-32-bits
Common Var(flag_interleaving_index_32_bits) Init(0) Optimization
Structure reorganization optimization, instance interleaving.

Note, I'm working around this but l'd really like
to not have to do so therefore I'm wondering if somebody
could explain what's happening and what I'd need
to do instead?


You defined the flag well.



Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.


Can you please remove this ugly notice that it's completely misleading? If not, 
I would then
recommend creating a private email.

Martin

Issue with a flag that I defined getting set to zero

[Gary Oblock via Gcc]

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 optimization, instance interleaving.

Note, I'm working around this but l'd really like
to not have to do so therefore I'm wondering if somebody
could explain what's happening and what I'd need
to do instead?

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.