Re: Obsolete powerpc*-*-*spe*
> On 21 Feb 2017, at 17:14, David Edelsohn wrote: > > Hi, Olivier > > There are three main areas that require attention: > > 1) Regular builds of the SPE configuration and regular GCC testsuite > runs that are reported to the gcc-testsuite mailing list. > > 2) Timely reports of any regressions. > > 3) An active GCC developer who is the point of contact for the SPE > port and submits patches for the port. > > None of us within IBM are experts on the SPE port. Someone from the > SPE community is needed to help triage issues, debug problems and test > patches that may affect the SPE port. > > With evidence of pro-active involvement from an SPE developer, the > port does not have to be deprecated. The effort needs to be more that > activity at GCC release cycle boundaries or an accelerated deprecation > process will be proposed. Sure. Thanks David, Olivier
Re: Obsolete powerpc*-*-*spe*
> > There are three main areas that require attention: > > > > 1) Regular builds of the SPE configuration and regular GCC testsuite > > runs that are reported to the gcc-testsuite mailing list. > > > > 2) Timely reports of any regressions. > > > > 3) An active GCC developer who is the point of contact for the SPE > > port and submits patches for the port. > > > > None of us within IBM are experts on the SPE port. Someone from the > > SPE community is needed to help triage issues, debug problems and test > > patches that may affect the SPE port. > > > > With evidence of pro-active involvement from an SPE developer, the > > port does not have to be deprecated. The effort needs to be more that > > activity at GCC release cycle boundaries or an accelerated deprecation > > process will be proposed. Thanks for your feedback David. Note that AdaCore has a direct interest in keeping this port live for the time being hence our questions. We are discussing internally whether some of us at AdaCore could step up to continue maintaining this port, so please stay tuned and involve us before making any decision :-) Arno
New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?
At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:
$ cat test.c
#include
int main() {
char buf[3];
snprintf(buf, sizeof buf, "%s", "foo");
return 0;
}
$ gcc -Wformat-truncation -Og ~/test.c
$ gcc -Wformat-truncation -O ~/test.c
test.c: In function ‘main’:
test.c:4:34: warning: ‘snprintf’ output truncated before the last format
character [-Wformat-truncation=]
snprintf(buf, sizeof buf, "%s", "foo");
^
test.c:4:5: note: ‘snprintf’ output 4 bytes into a destination of size 3
snprintf(buf, sizeof buf, "%s", "foo");
^~
Any other optimization level (-O1..3/s/fast) does emit the warning. The
documentation makes it clear that the behavior of that warning may be
coupled to the optimization level, but this difference between -Og and
everything else still looks somewhat odd. Could it be by mistake?
Re: New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?
On 02/23/2017 02:51 PM, Stephan Bergmann wrote:
At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:
$ cat test.c
#include
int main() {
char buf[3];
snprintf(buf, sizeof buf, "%s", "foo");
return 0;
}
$ gcc -Wformat-truncation -Og ~/test.c
$ gcc -Wformat-truncation -O ~/test.c
test.c: In function ‘main’:
test.c:4:34: warning: ‘snprintf’ output truncated before the last
format character [-Wformat-truncation=]
snprintf(buf, sizeof buf, "%s", "foo");
^
test.c:4:5: note: ‘snprintf’ output 4 bytes into a destination of size 3
snprintf(buf, sizeof buf, "%s", "foo");
^~
Any other optimization level (-O1..3/s/fast) does emit the warning. The
-O0..3, even
documentation makes it clear that the behavior of that warning may be
coupled to the optimization level, but this difference between -Og and
everything else still looks somewhat odd. Could it be by mistake?
Re: New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?
On 02/23/2017 06:51 AM, Stephan Bergmann wrote:
At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:
That's unfortunately a bug. The warning runs at different stages
depending on whether or not optimization is enabled and it looks
like the global GCC variable it uses to determine this is not set
for -Og. Can you please open a bug in Bugzilla?
Thanks
Martin
$ cat test.c
#include
int main() {
char buf[3];
snprintf(buf, sizeof buf, "%s", "foo");
return 0;
}
$ gcc -Wformat-truncation -Og ~/test.c
$ gcc -Wformat-truncation -O ~/test.c
test.c: In function ‘main’:
test.c:4:34: warning: ‘snprintf’ output truncated before the last
format character [-Wformat-truncation=]
snprintf(buf, sizeof buf, "%s", "foo");
^
test.c:4:5: note: ‘snprintf’ output 4 bytes into a destination of size 3
snprintf(buf, sizeof buf, "%s", "foo");
^~
Any other optimization level (-O1..3/s/fast) does emit the warning. The
documentation makes it clear that the behavior of that warning may be
coupled to the optimization level, but this difference between -Og and
everything else still looks somewhat odd. Could it be by mistake?
Re: New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?
On 02/23/2017 05:02 PM, Martin Sebor wrote:
On 02/23/2017 06:51 AM, Stephan Bergmann wrote:
At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:
That's unfortunately a bug. The warning runs at different stages
depending on whether or not optimization is enabled and it looks
like the global GCC variable it uses to determine this is not set
for -Og. Can you please open a bug in Bugzilla?
"-Wformat-truncation suppressed by (and only by) -Og"
RE: ICE in gcc.dg/pr77834.c test for MIPS
Hi Segher,
Thank you for replying.
> From: Segher Boessenkool
>
> This happens when you have inserted code ending in a jump on an edge.
> This then will need updating of the CFG, and this code does not know
> how to do that.
>
Would the following be an appropriate solution ?
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index cafa38d..898d909 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -2047,6 +2047,16 @@ commit_one_edge_insertion (edge e)
after = BB_END (bb);
}
+ /* If the edge contains control flow instructions, remember to update the
+ CFG after the insertion. */
+ bool update_cfg = false;
+ for (tmp = insns; tmp && update_cfg == false; tmp = NEXT_INSN (tmp))
+ if (control_flow_insn_p (tmp))
+ {
+update_cfg = true;
+break;
+ }
+
/* Now that we've found the spot, do the insertion. */
if (before)
{
@@ -2056,6 +2066,15 @@ commit_one_edge_insertion (edge e)
else
last = emit_insn_after_noloc (insns, after, bb);
+ if (update_cfg)
+{
+ auto_sbitmap blocks (last_basic_block_for_fn (cfun));
+ bitmap_ones (blocks);
+ find_many_sub_basic_blocks (blocks);
+
+ last = BB_END (bb);
+}
+
if (returnjump_p (last))
{
/* ??? Remove all outgoing edges from BB and add one for EXIT.
In short, I'm updating the CFG by calling find_many_sub_basic_blocks with an
all-one block bitmap (this also happens in cfgexpand.c, after the edge
insertions) whenever an edge contains an insn which satisfies
control_flow_insn_p.
Regards,
Toma
Re: ICE in gcc.dg/pr77834.c test for MIPS
Hi Toma,
On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > This happens when you have inserted code ending in a jump on an edge.
> > This then will need updating of the CFG, and this code does not know
> > how to do that.
>
> Would the following be an appropriate solution ?
[ snip ]
> @@ -2047,6 +2047,16 @@ commit_one_edge_insertion (edge e)
> + /* If the edge contains control flow instructions, remember to update the
> + CFG after the insertion. */
I don't know what all can break if you allow control flow insns in
insert_insn_on_edge -- this function is called from many different
passes, many things can break -- but this does look like it should work.
> + bool update_cfg = false;
> + for (tmp = insns; tmp && update_cfg == false; tmp = NEXT_INSN (tmp))
> + if (control_flow_insn_p (tmp))
> + {
> + update_cfg = true;
> + break;
> + }
> + if (update_cfg)
> +{
> + auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> + bitmap_ones (blocks);
> + find_many_sub_basic_blocks (blocks);
> +
> + last = BB_END (bb);
> +}
Maybe you can keep track of what blocks to split, instead of just saying
"all".
> In short, I'm updating the CFG by calling find_many_sub_basic_blocks with an
> all-one block bitmap (this also happens in cfgexpand.c, after the edge
> insertions) whenever an edge contains an insn which satisfies
> control_flow_insn_p.
Can't whatever creates those jump insns keep the cfg in shape? That
would avoid all issues here.
General... Patches need to go to gcc-patches@. You also should have
your copyright assignment in order (I have no idea if you do; if you
do, please ignore). Finally, trunk currently is in stage 4, this work
will need to wait for stage 1 (a couple of months, something like that).
Segher
gcc-6-20170223 is now available
Snapshot gcc-6-20170223 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170223/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 245690 You'll find: gcc-6-20170223.tar.bz2 Complete GCC MD5=1498ca54fa96fffd771f3f917fc40b80 SHA1=f37119344cf998dd7fcc56fb036c16f80d7bc71a Diffs from 6-20170216 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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: ICE in gcc.dg/pr77834.c test for MIPS
Segher Boessenkool writes:
> On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > > This happens when you have inserted code ending in a jump on an
> edge.
> > > This then will need updating of the CFG, and this code does not know
> > > how to do that.
> >
> > Would the following be an appropriate solution ?
>
> [ snip ]
>
> > @@ -2047,6 +2047,16 @@ commit_one_edge_insertion (edge e)
> > + /* If the edge contains control flow instructions, remember to
> update the
> > + CFG after the insertion. */
>
> I don't know what all can break if you allow control flow insns in
> insert_insn_on_edge -- this function is called from many different
> passes, many things can break -- but this does look like it should work.
>
> > + bool update_cfg = false;
> > + for (tmp = insns; tmp && update_cfg == false; tmp = NEXT_INSN
> (tmp))
> > + if (control_flow_insn_p (tmp))
> > + {
> > +update_cfg = true;
> > +break;
> > + }
>
> > + if (update_cfg)
> > +{
> > + auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> > + bitmap_ones (blocks);
> > + find_many_sub_basic_blocks (blocks);
> > +
> > + last = BB_END (bb);
> > +}
>
> Maybe you can keep track of what blocks to split, instead of just saying
> "all".
>
> > In short, I'm updating the CFG by calling find_many_sub_basic_blocks
> > with an all-one block bitmap (this also happens in cfgexpand.c, after
> > the edge
> > insertions) whenever an edge contains an insn which satisfies
> control_flow_insn_p.
>
> General... Patches need to go to gcc-patches@. You also should have
> your copyright assignment in order (I have no idea if you do; if you do,
> please ignore). Finally, trunk currently is in stage 4, this work will
> need to wait for stage 1 (a couple of months, something like that).
This is an ICE that will be reproducible on a primary target so is still
appropriate to pursue in stage4 as far as I understand. I'm hoping to
find time to work with Toma on this issue.
> Can't whatever creates those jump insns keep the cfg in shape? That
> would avoid all issues here.
The problem, I think, is that these instructions are not yet in the cfg
and are being inserted on an edge. The jump is produced from the inline
memcpy expansion we do for MIPS. In some cases there will be no loop,
some cases there will be a loop ending with the conditional jump and
some cases will have a loop and other instructions after the conditional
jump. The 1st and 3rd form will get through the logic in
commit_one_edge_insertion (albeit that the 3rd form will have incorrect
cfg actually) but the 2nd form is rejected because of ending with a jump.
Other than coping with the potential for sub blocks here or letting them
through and leaving later code to split the blocks then I see no other
way forward. I agree it should be possible to process just the blocks
with jump instructions in the middle and that is actually going to be
exactly one block in this case. I don't know if updating the CFG while
edges are being iterated on in commit_edge_insertions is safe though
and am somewhat out of my comfort zone in general!
Thanks,
Matthew
Re: ICE in gcc.dg/pr77834.c test for MIPS
On Thu, Feb 23, 2017 at 10:43:36PM +, Matthew Fortune wrote: > This is an ICE that will be reproducible on a primary target so is still > appropriate to pursue in stage4 as far as I understand. I'm hoping to > find time to work with Toma on this issue. Ah. Is there a PR for it yet? Please open one, if not. > > Can't whatever creates those jump insns keep the cfg in shape? That > > would avoid all issues here. > > The problem, I think, is that these instructions are not yet in the cfg > and are being inserted on an edge. The jump is produced from the inline > memcpy expansion we do for MIPS. So this is generated during expand? I don't see how it ends up on an edge. > In some cases there will be no loop, > some cases there will be a loop ending with the conditional jump and > some cases will have a loop and other instructions after the conditional > jump. The 1st and 3rd form will get through the logic in > commit_one_edge_insertion (albeit that the 3rd form will have incorrect > cfg actually) but the 2nd form is rejected because of ending with a jump. You can easily turn the 2nd form into the 3rd by emitting some no-op instruction last. If you can live with 3rd for GCC 7, that may be a good solution for now. > Other than coping with the potential for sub blocks here or letting them > through and leaving later code to split the blocks then I see no other > way forward. I agree it should be possible to process just the blocks > with jump instructions in the middle and that is actually going to be > exactly one block in this case. I don't know if updating the CFG while > edges are being iterated on in commit_edge_insertions is safe though > and am somewhat out of my comfort zone in general! Yeah I'm really not seeing where/when your movmem is emitted. Segher
