[Bug c++/78843] New: error: 'functionname' was not declared in this scope

[jmichae3 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78843

Bug ID: 78843
   Summary: error: 'functionname' was not declared in this scope
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

End of search list.
COLLECT_GCC_OPTIONS='-O2' '-save-temps' '-v' '-static' '-s' '-std=c++14' '-o'
'32\find.exe' '-mtune=generic' '-march=i686'
 c:/program
files/mingw-w64/i686-6.2.0-win32-sjlj-rt_v5-rev1/mingw32/bin/../libexec/gcc/i686-w64-mingw32/6.2.0/cc1plus.exe
-fpreprocessed find.ii -quiet -dumpbase find.cpp -mtune=generic -march=i686
-auxbase find -O2 -std=c++14 -version -o find.s
GNU C++14 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) version 6.2.0
(i686-w64-mingw32)
compiled by GNU C version 6.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129741
GNU C++14 (i686-win32-sjlj-rev1, Built by MinGW-W64 project) version 6.2.0
(i686-w64-mingw32)
compiled by GNU C version 6.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129741
Compiler executable checksum: ae018ebc3c12849135049d8ce622ca81


find.cpp: In function 'bool walkDirTree(std::__cxx11::string, VSDF&, int64_t,
bool)':
find.cpp:498:41: error: 'vsOSSortCompare' was not declared in this scope
 std::sort(dirs.begin(), dirs.end(), vsOSSortCompare);
 ^~~
find.cpp:499:54: error: 'vsOSUniqueCompare' was not declared in this scope
 VSI vsiDir=std::unique(dirs.begin(), dirs.end(), vsOSUniqueCompare);



funny thing is, both functions *are* declared before their use. I #included a
header file which has:
bool VSOSUniqueCompare(std::string first, std::string second/*, bool
icase=false*/);

bool VSOSSortCompare(std::string first, std::string second/*, bool
icase=false*/);

[Bug c++/78842] New: "error: declaration of 'bool icase' shadows a parameter" should be warning

[jmichae3 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78842

Bug ID: 78842
   Summary: "error: declaration of 'bool icase' shadows a
parameter" should be warning
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmichae3 at yahoo dot com
  Target Milestone: ---

find.cpp:128:6: error: declaration of 'bool icase' shadows a parameter
 bool icase=false;
std::vector find_vsizet(std::string haystack, std::string needle, bool
icase=false, size_t pos=0);



this should be a warning, not an error. the local scope of the function arg
icase excludes the global icase doesn't it?

is this an attempt to fix "bad-looking" code, or are you following spec?

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-17
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
ENOATTACHMENT

[Bug c++/78826] jump bypasses non-POD

[aurzenligl at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826

--- Comment #3 from Krzysztof Laskowski  ---
(In reply to Jonathan Wakely from comment #2)
> I assume GCC 4.5 stopped diagnosing it due to the revised specification
> which only cares about trivial constructor or trivial destructor, not
> PODness.
I couldn't actually find any clause allowing jump over trivially constructed
variable in ISO/IEC 14882:1998 nor ISO/IEC 14882:2003. Moreover, icc (13, 16,
17) and clang (3.0-3.9) warn and err, respectively, on example.

It seems to correlate with introducing c++0x support in gcc.
https://gcc.gnu.org/gcc-4.5/changes.html
"Diagnostics that used to complain about passing non-POD types to ... or
jumping past the declaration of a non-POD variable now check for triviality
rather than PODness, as per C++0x."

> Giving a diagnostic here would just be pedantic and unhelpful.
I agree it's harmless to bypass trivially constructed variable. Does it mean
that it's a deliberate deviation from standard for the sake of ease of c++11
implementation at the cost of portability/conformance?

[Bug c++/78841] New: [6 regression] optimizer bug (silent bad codegen)

[Casey at Carter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78841

Bug ID: 78841
   Summary: [6 regression] optimizer bug (silent bad codegen)
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

g++ 6.2 (not 5.4, or 4.9, or 4.8, or trunk) generates bad code for the attached
repro at -O2 and higher. "silent bad codegen" just barely trumps "already fixed
on trunk" to my mind, so here's a repro; my feelings won't be hurt if you
WONTFIX this.

Apologies for the huge repro, I've had a hard time reducing it from here
without making the bug disappear.

[Bug c++/78840] New: ICE with const variables in templates implicitly captured by nested lambda expressions

[myoga.murase at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78840

Bug ID: 78840
   Summary: ICE with const variables in templates implicitly
captured by nested lambda expressions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myoga.murase at gmail dot com
  Target Milestone: ---

The following valid C++ code causes an internal compiler error in recent
versions of GCC from 5.1.0 to 7.0.0 20161216. Earlier versions from 4.5.4 to
4.9.4, and clang successfully compiles the code.

http://melpon.org/wandbox/permlink/hJM9b4zWQzTJeBLp

int gvar;

template void tfunc2(int, F) {}

template void tfunc() { // ICE is caused when, in function templates,
  const int a = gvar; // a const variable initialized by a non-const value
  tfunc2(a, [&]() {
tfunc2(a, [&]() {
  (void) a; // is used in nested lambda expressions.
});
  });
}

int main() {
  tfunc<1>();
  return 0;
}


This is the diagnostic messages from GCC 7.0.0 20161216:

prog.cc: In instantiation of 'tfunc()::<lambda()>::<lambda()> [with int I =
1]':
prog.cc:9:17:   required from 'struct tfunc()::<lambda()> [with int I =
1]::<lambda()>'
prog.cc:9:11:   required from 'tfunc()::<lambda()> [with int I = 1]'
prog.cc:8:15:   required from 'struct tfunc() [with int I = 1]::<lambda()>'
prog.cc:8:9:   required from 'void tfunc() [with int I = 1]'
prog.cc:16:12:   required from here
prog.cc:10:7: internal compiler error: in tsubst_copy, at cp/pt.c:14294
   (void) a;
   ^~~~
0x61e089 tsubst_copy
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14292
0x6254b3 tsubst_copy
/home/heads/gcc/gcc-source/gcc/cp/pt.c:14119
0x6254b3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:17397
0x6271e8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:17159
0x6269bc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16421
0x61aeb7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16146
0x619925 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15414
0x61ace3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15624
0x61ace3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15624
0x619372 instantiate_decl(tree_node*, int, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:22560
0x62ce2d instantiate_class_template_1
/home/heads/gcc/gcc-source/gcc/cp/pt.c:10449
0x62ce2d instantiate_class_template(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:10519
0x68f5e5 complete_type(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/typeck.c:133
0x624e39 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:17522
0x6266de tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16836
0x61aeb7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:16146
0x619925 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15414
0x61aa95 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15400
0x61ace3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15624
0x61ace3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15624
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c++/78826] jump bypasses non-POD

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826

--- Comment #2 from Jonathan Wakely  ---
GCC 4.4.7 gives an error:

pod.cc: In function ‘void should_not_compile()’:
pod.cc:6: error: jump to label ‘label’
pod.cc:4: error:   from here
pod.cc:5: error:   enters scope of non-POD ‘non_pod_in_cpp03 x’

I assume GCC 4.5 stopped diagnosing it due to the revised specification which
only cares about trivial constructor or trivial destructor, not PODness. So I
suspect this change in behaviour is by design.

The type in your program does not have non-trivial constructor or non-trivial
destructor, so there is no danger in jumping over its initialization. Giving a
diagnostic here would just be pedantic and unhelpful.

[Bug other/78839] DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #6 from Tom O'Connor  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Tom O'Connor from comment #4)
> > Bitfields seemed to work fine in all GCC prior to 6, FWIW.  The same
> > attached source code when built with other GCCs prior to 6 generates
> > DW_AT_data_member_location = 0 for all the fields as expected.  Only 6 gets
> > some of the fields "wrong".
> 
> Maybe I am thinking big-endian :).

Ah, I've only observed this on little-endian, as that's the only place I've
looked.

[Bug other/78839] DWARF output different between GCC 5 and 6

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #5 from Andrew Pinski  ---
(In reply to Tom O'Connor from comment #4)
> Bitfields seemed to work fine in all GCC prior to 6, FWIW.  The same
> attached source code when built with other GCCs prior to 6 generates
> DW_AT_data_member_location = 0 for all the fields as expected.  Only 6 gets
> some of the fields "wrong".

Maybe I am thinking big-endian :).

[Bug other/78839] DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #4 from Tom O'Connor  ---
Bitfields seemed to work fine in all GCC prior to 6, FWIW.  The same attached
source code when built with other GCCs prior to 6 generates
DW_AT_data_member_location = 0 for all the fields as expected.  Only 6 gets
some of the fields "wrong".

[Bug other/78839] DWARF output different between GCC 5 and 6

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #3 from Andrew Pinski  ---
IIRC bitfield are broken for dwarf2/3 and there is another mechanism for them
for dwarf5.

RE: Re: DWARF output different between GCC 5 and 6

[Tom O'Connor]

Opened as bug 78839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

From: Jakub Jelinek [ja...@redhat.com]
Sent: Friday, December 16, 2016 6:03 PM
To: Tom O'Connor
Cc: gcc@gcc.gnu.org
Subject: EXTERNAL: Re: DWARF output different between GCC 5 and 6

On Fri, Dec 16, 2016 at 10:30:09PM +, Tom O'Connor wrote:
> I've observed a difference in DWARF output for the same input source code
> between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location
> values for bitfield members of structs.  For example,

This changed with http://gcc.gnu.org/r231762 .
Please file a bugreport in http://gcc.gnu.org/bugzilla/

Jakub
Scanned by Forcepoint Email Security Gateway

To report this email as SPAM, please forward it to s...@forcepoint.com

[Bug other/78839] DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #2 from Tom O'Connor  ---
Created attachment 40355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40355=edit
debuginfo from a GCC 6.1.0 build of s.c

[Bug other/78839] DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #1 from Tom O'Connor  ---
Created attachment 40354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40354=edit
debuginfo from a GCC 5.4.0 build of s.c

[Bug other/78839] New: DWARF output different between GCC 5 and 6

[toconnor at forcepoint dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Bug ID: 78839
   Summary: DWARF output different between GCC 5 and 6
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toconnor at forcepoint dot com
  Target Milestone: ---

Created attachment 40353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40353=edit
sample c code

I've observed a difference in DWARF output for the same input source code
between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location values
for bitfield members of structs. For example,

s.c:
struct s {
  unsigned int shutdown:2,
no_check_tx:1,
no_check_rx:1,
userlocks:4,
protocol:8,
type:16;
};

int main() {
  struct s s;
  return 0;
}


GCC 5 reports DW_AT_data_member_location for all the fields as 0, which is
expected.
GCC 6 reports DW_AT_data_member_location for the "type" and "protocol" fields
as 2 and 1 respectively, all other fields 0 as expected. The DW_AT_bt_offset
fields for "type" and "protocol" change as well.

According to a mailing list posting, this is related to this change: 
http://gcc.gnu.org/r231762

[PATCH v2,rs6000] PR78056: Finish fixing build failure on Power7

[Kelvin Nilsen]

This patch adds warning messages and test cases to an initial patch
already submitted and committed to the trunk on October 26, 2016.  The
earlier patch disables initialization of built-in functions which depend
on assembler capabilities that are not supported by the associated tool
chain.

The original patch was submitted before the work was considered
complete because it was desired to expedite a fix to allow builds on
Power7.  At the time the original patch was submitted for approval, the
following additional tasks were planned.

1. Fail with an assertion error instead of an internal compiler error
if built-in functions are ever defined for which the corresponding
instruction pattern is not supported by the current compiler
configuration.

2. Issue a warning message whenever a command-line -mcpu=XXX request
seeks to configure support for a CPU version which is not supported by
the accompanying assembler.

Besides addressing the above tasks, this new patch also adds a number
of tests to exercise different target configurations.

This second version of the patch differs from the first revision
(which had been sent for review on Dec. 9) in the following ways:

1. Removed #define directives from rs6000.c which were defining
HAVE_AS_POWER9, HAVE_AS_POWER8, HAVE_AS_POPCNTD, HAVE_AS_DFP, and
HAVE_AS_POPCNTB macros.  Rewrote the code that made use of these
macros to be conditioned on #ifdef.

2. Removed redundant parentheses in an expression that defines
the value of the default_cpu variable.

3. Replaced multiple occurrences of (d->icode > 0) with
(d->icode != CODE_FOR_nothing).

4. Replaced two comments which claimed that it is expected
that d->icode equals CODE_FOR_nothing to say instead that
d->icode may equal CODE_FOR_nothing.

5. Added a new effective-target named powerpc_popcntb_ok
and required this effective target in the pr78056-8.c test case.

The patch has been tested with three different tool chains supporting
up to power7, power8, and power9 respectively.  It has successfully
bootstrapped and tested without regressions on
powerpc64le-unknown-linux and powerpc-unknown-linux (big-endian, with
both -m32 and -m64 target options) with no regressions.

Is this patch ok for trunk?

gcc/testsuite/ChangeLog:

2016-12-16  Kelvin Nilsen  

PR target/78056
* gcc.target/powerpc/pr78056-1.c: New test.
* gcc.target/powerpc/pr78056-2.c: New test.
* gcc.target/powerpc/pr78056-3.c: New test.
* gcc.target/powerpc/pr78056-4.c: New test.
* gcc.target/powerpc/pr78056-5.c: New test.
* gcc.target/powerpc/pr78056-6.c: New test.
* gcc.target/powerpc/pr78056-7.c: New test.
* gcc.target/powerpc/pr78056-8.c: New test.
* lib/target-supports.exp
(check_effective_target_powerpc_popcntb_ok): New procedure to test
whether the effective target supports the popcntb instruction.

gcc/ChangeLog:

2016-12-16  Kelvin Nilsen  

PR target/78056
* doc/sourcebuild.texi (PowerPC-specific attributes): Add
documentation of the powerpc_popcntb_ok attribute.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
code to issue warning messages if a requested CPU configuration is
not supported by the binary (assembler and loader) toolchain.
(spe_init_builtins): Add two assertions to prevent ICE if attempt is
made to define a built-in function that has been disabled.
(paired_init_builtins): Add assertion to prevent ICE if attempt is
made to define a built-in function that has been disabled.
(altivec_init_builtins): Add comment explaining why definition
of the DST built-in functions is not preceded by an assertion
check.  Add assertions to prevent ICE if attempts are made to
define an altivec predicate or an abs* built-in function that has
been disabled.
(htm_init_builtins): Add comment explaining why definition of the
htm built-in functions is not preceded by an assertion check.


Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi(revision 241606)
+++ gcc/doc/sourcebuild.texi(working copy)
@@ -1763,6 +1763,10 @@ PowerPC target supports @code{-mhtm}
 @item powerpc_p8vector_ok
 PowerPC target supports @code{-mpower8-vector}
 
+@item powerpc_popcntb_ok
+PowerPC target supports the @code{popcntb} instruction, indicating
+that this target supports @code{-mcpu=power5}.
+
 @item powerpc_ppu_ok
 PowerPC target supports @code{-mcpu=cell}.
 
Index: gcc/testsuite/gcc.target/powerpc/pr78056-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr78056-1.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr78056-1.c(revision 241861)
@@ -0,0 +1,18 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not 

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216

--- Comment #8 from Segher Boessenkool  ---
Hi Rin,

> However, I have a question on this fix. How about the case where
> "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?

That might or might not work; the user had better know what he is
doing if he uses an assembler option.

> This may sound pedantic to you. However, this is dangerous because
> some special mnemonics in inline assembler codes can be misassembled.
> In addition, for example, "-mcpu=e500" is forbidden whereas "-Wa,-me500"
> is possible; the user cannot use instructions for e500 in inline
> assembler codes.

GCC does not support -me500, right.  You need to configure your compiler
for a powerpc-*-eabispe* target as far as I know (I'm no expert on this).

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

--- Comment #9 from joseph at codesourcery dot com  ---
That LRA patch (on top of the previous patch) allows the glibc build to 
complete.  Now running gcc/g++/libstdc++ testsuites (I haven't run them 
with an unmodified copy of the same GCC version, so this will only provide 
a rough comparison against results from my previous testing of older trunk 
on 23 November).

Re: [PATCH] builtin expansion of strncmp for rs6000

[Segher Boessenkool]

Hi Aaron,

On Thu, Dec 15, 2016 at 10:31:05AM -0600, Aaron Sawdey wrote:
> This patch adds a cmpstrnsi pattern for rs6000 target to provide
> builtin expansion of strncmp(). Perf tests on a power8 system show that
> it is 3-10x faster than the glibc strncmp on RHEL7 for lengths under 64
> bytes.
> 
> Bootstrap/regtest has passed on powerpc64le, in progress for powerpc64,
> ok for trunk if no new regressions?

Some trivial things...

> +static void
> +expand_strncmp_align_check (rtx strncmp_label, rtx src, HOST_WIDE_INT bytes)
> +{
> +  rtx lab_ref = gen_rtx_LABEL_REF (VOIDmode, strncmp_label);
> +  rtx src_check = copy_addr_to_reg (XEXP (src, 0));
> +  if (GET_MODE (src_check) == SImode)
> +emit_insn (gen_andsi3_mask (src_check, src_check, GEN_INT(0xfff)));

Space before (, also for macros.

> +  else
> +emit_insn (gen_anddi3_mask (src_check, src_check, GEN_INT(0xfff)));

You can also just do gen_anddi3 (..); sometimes it can optimise better that
way, you can easier be sure you match all constraints, and it requires less
thinking.  Just for expanders of course, code that runs later needs to do
more by hand to get good results.  (There's no need to change it here, just
a FYI).

> +  rtx cond = gen_reg_rtx (CCmode);
> +  emit_move_insn (cond, gen_rtx_COMPARE (CCmode, src_check,
> +  GEN_INT (4096-bytes)));

Spaces around -.

>  

You put the page break in the middle of a function.  Let's not :-)

> +/* Expand a string compare operation with length, and return 
> +   true if successful. Return false if we should let the 

These two lines have trailing spaces. There is more of this; please
check everything.

> +  if (align1 < 8)
> + expand_strncmp_align_check (strncmp_label, src1, bytes);
> +  if (align2 < 8)
> + expand_strncmp_align_check (strncmp_label, src2, bytes);

Does this work out if (say) bytes >= 4096?  It doesn't have to be very
sane code, but it should work correctly.  Or you need to limit the maximum
size some other way.

> +  /* Now generate the following sequence:
> +  - branch to begin_compare
> +  - strncmp_label
> +  - call to strncmp
> +  - branch to final_label 
> + - begin_compare_label */

Wrong indent on that last line.

> +  /* -m32 -mpowerpc64 results in word_mode being DImode even
> +  though otherwise it is 32-bit. The length arg to strncmp
> +  is a size_t which will be the same size as pointers.  */
> +  rtx len_rtx;
> +  if (TARGET_64BIT)
> + len_rtx = gen_reg_rtx(DImode);
> +  else
> + len_rtx = gen_reg_rtx(SImode);
> + 

Wrong tab.  Some more tab vs. spaces indent (and white space at the end
of line) follows, please fix all.

> +  /* We must always left-align the data we read, and
> +  clear any bytes to the right that are beyond the string.
> +  Otherwise the cmpb sequence won't produce the correct
> +  results.  The beginning of the compare will be done
> +  with word_mode so will not have any extra shifts or
> +  clear rights.  */
> +
> +  if ( load_mode_size < word_mode_size )

No space after ( or before ).

> +   rtx mask = GEN_INT (~(((HOST_WIDE_INT)1 << mb) - 1));

  rtx mask = GEN_INT (HOST_WIDE_INT_M1U << mb);

Please repost.  Thanks,


Segher

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work|6.2.0, 7.0  |
   Target Milestone|6.2 |7.0
  Known to fail||6.2.0

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> The test in comment 0 is still giving an off by 1 result (7.0 at r243758):

Right, I missed that. Sorry for closing too early. Reduced test case for the
remaining failure:


module m2
  implicit none
  type :: t_stv
real :: f1
  end type
contains
  subroutine lcb(y)
class(t_stv), intent(in) :: y(:)
integer :: k
write(*,*) 'Inside LCB: size is ',size(y)
do k=1,size(y)
  write(*,*) 'f1: ', k, y(k)%f1
enddo
  end subroutine
end module

program test
 use m2
 implicit none

 type(t_stv), allocatable :: work(:)

  allocate(work(4))
  work(:)%f1 = (/ 1.,2.,3.,4./)

  write(*,*) 'Call with whole array: works fine'
  call lcb(work)
  write(*,*) 'Call with array slice: off by 1'
  call lcb(work(:4))

end program


Prints:

 Call with whole array: works fine
 Inside LCB: size is4
 f1:1   1.
 f1:2   2.
 f1:3   3.
 f1:4   4.
 Call with array slice: off by 1
 Inside LCB: size is4
 f1:1   2.
 f1:2   3.
 f1:3   4.
 f1:4   0.

Re: DWARF output different between GCC 5 and 6

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 10:30:09PM +, Tom O'Connor wrote:
> I've observed a difference in DWARF output for the same input source code
> between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location
> values for bitfield members of structs.  For example,

This changed with http://gcc.gnu.org/r231762 .
Please file a bugreport in http://gcc.gnu.org/bugzilla/

Jakub

[Bug target/78838] New: msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created

[awygle at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838

Bug ID: 78838
   Summary: msp430 option -mcode-region=either,
-ffunction-sections, and interrupt function attributes
cause incorrect section to be created
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awygle at gmail dot com
  Target Milestone: ---

On the msp430 target, when using -mcode-region with -ffunction-sections (as is
semi-suggested by the documentation), any functions which are marked with the
interrupt attribute and which also specify an interrupt number are placed into
an incorrect section ".either.lowtext", which is clearly nonsensical. An
example is below.

interrupt_bug.i:

# 1 "interrupt_bug.c"
# 1 ""
# 1 ""
# 1 "interrupt_bug.c"

__attribute__((interrupt(2))) void causes_error(void) {
}

void main() {

  while(1);
}

Compiling with -ffunction-sections:

% msp430-elf-gcc -msim -mlarge -mcode-region=either -ffunction-sections
-save-temps -c interrupt_bug.c -o interrupt_bug.o
% msp430-elf-gcc -msim -mlarge -mcode-region=either -ffunction-sections
-save-temps interrupt_bug.o -o interrupt_bug.elf
/home/awygle/toolchain/install/bin/../lib/gcc/msp430-elf/6.2.0/../../../../msp430-elf/bin/ld:
error: no section named .lower.lowtext or .upper.lowtext in linker script
% msp430-elf-objdump --syms interrupt_bug.o

interrupt_bug.o: file format elf32-msp430

SYMBOL TABLE:
 ldf *ABS*   interrupt_bug.c
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .either.lowtext .either.lowtext
 ld  __interrupt_vector_2    __interrupt_vector_2
 ld  .either.text.main   .either.text.main
 ld  .comment    .comment
 ld  .MSP430.attributes  .MSP430.attributes
 g F .either.lowtext0004 causes_error
 g F .either.text.main  0004 main


Note that main() is in the section .either.text.main, while causes_error() is
in the section .either.lowtext.

Compiling without -ffunction-sections:

% msp430-elf-gcc -msim -mlarge -mcode-region=either -save-temps -c
interrupt_bug.c -o interrupt_bug.o
% msp430-elf-gcc -msim -mlarge -mcode-region=either -save-temps interrupt_bug.o
-o interrupt_bug.elf
% msp430-elf-objdump --syms interrupt_bug.o

interrupt_bug.o: file format elf32-msp430

SYMBOL TABLE:
 ldf *ABS*   interrupt_bug.c
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .lowtext    .lowtext
 ld  __interrupt_vector_2    __interrupt_vector_2
 ld  .either.text    .either.text
 ld  .comment    .comment
 ld  .MSP430.attributes  .MSP430.attributes
 g F .lowtext   0004 causes_error
 g F .either.text   0004 main


Now causes_error() is in the .lowtext section, as expected.

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[e...@sf-mail.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936

--- Comment #11 from Rolf Eike Beer  ---
I configured with:

../gcc-host/configure --target=i686-unknown-linux-gnu --host=x86_64-pc-linux-
gnu --build=x86_64-pc-linux-gnu --program-prefix=i686-unknown-linux-gnu- --
with-sysroot=/opt/emlix/test/sysroot --with-build-sysroot=/opt/emlix/test/
sysroot --with-gxx-include-dir=/opt/emlix/test/sysroot/usr/include/c++/6.2.0 
--with-gnu-as --with-gnu-ld --enable-__cxa_atexit --enable-c99 --enable-
clocale=gnu --with-system-zlib --enable-long-long --disable-multilib --enable-
threads=posix --prefix=/opt/emlix/test --mandir=/opt/emlix/test/share/man --
infodir=/opt/emlix/test/share/info --enable-libssp --enable-libgomp --disable-
gcj --disable-sjlj-exceptions --enable-languages=c,c++ --disable-interpreter 
--disable-libstdcxx-pch --with-gmp=/opt/emlix/test --with-mpfr=/opt/emlix/test 
--with-mpc=/opt/emlix/test --without-ppl --without-cloog --with-slibdir=/opt/
emlix/test/sysroot/lib --with-build-time-tools=/opt/emlix/test/i686-unknown-
linux-gnu/bin '--with-pkgversion=emlix Linux Test-BSP'

Please note that the --with-gxx-include-dir is not the culprit, the failure
happens also without it.

Re: [LRA] Fix ICE for paradoxical subregs on strict-alignment platforms

[Vladimir N Makarov]

On 12/13/2016 05:05 PM, Eric Botcazou wrote:

Hi,

the Ada runtime library doesn't build on SPARC 32-bit with LRA because of an
ICE on a couple of files:

eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/gnat1 -I gcc/ada/rts -
quiet -dumpbase g-debpoo.adb -auxbase g-debpoo -O2 -gnatpg -fPIC -mlra -
mcpu=v9 g-debpoo.adb -o g-debpoo.s
+===GNAT BUG DETECTED==+
| 7.0.0 20161213 (experimental) [trunk revision 243595] (sparc-sun-
solaris2.10) GCC error:|
| in lra_set_insn_recog_data, at lra.c:965 |
| Error detected around g-debpoo.adb:1896:8

The problem is that curr_insn_transform attempts to reload subregs before
reloading addresses:

   if (! check_only_p)
 /* Make equivalence substitution and memory subreg elimination
before address processing because an address legitimacy can
depend on memory mode.  */

Now, on strict-alignment platforms, simplify_operand_subreg has a special
provision for paradoxical subregs of memory references:

 /* If we change the address for a paradoxical subreg of memory, the
address might violate the necessary alignment or the access might
be slow.  So take this into consideration.  We need not worry
about accesses beyond allocated memory for paradoxical memory
subregs as we don't substitute such equiv memory (see processing
equivalences in function lra_constraints) and because for spilled
pseudos we allocate stack memory enough for the biggest
corresponding paradoxical subreg.  */
  if (!(MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (mode)
&& SLOW_UNALIGNED_ACCESS (mode, MEM_ALIGN (reg)))
  || (MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (innermode)
  && SLOW_UNALIGNED_ACCESS (innermode, MEM_ALIGN (reg
return true;

That is to say, if the adjusted memory reference is not sufficient aligned,
the routine will reload the original memory reference instead of the adjusted
one on strict-alignment platforms.  But there is a hitch: if the address of
this original memory reference is invalid, the routine will nevertheless
reload the entire memory reference, leading to the aforementioned ICE.

The proposed fix is to reload the address, if it is invalid, just before
reloading the memory reference in simplify_operand_subreg; this yields the
correct sequence of reloads for the case I investigated.  The patch also
contains formatting fixes and adds a 'return' for the sake of clarity.

Tested on x86-64/Linux and SPARC/Solaris with LRA, OK for the mainline?

OK.  Thanks for working on this issue, Eric.

The subreg reload code is very sensitive to changes and actually had a 
lot of changes.  So we should be aware that the patch might create new 
PRs.  But I believe the probability of this is tiny.




2016-12-13  Eric Botcazou  

* lra-constraints.c (process_address): Add forward declaration.
(simplify_operand_subreg): In the MEM case, if the adjusted memory
reference is not sufficient aligned and the address was invalid,
reload the address before reloading the original memory reference.
Fix long lines and add a final return for the sake of clarity.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516

Peter Bergner  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #8 from Peter Bergner  ---
Adding Vlad as this seems like it may be a LRA bug...or we at least need his
input about what we should be doing.

We have the following "fixed" pattern from the updated fix patch attached
above:

(define_insn "*mov_si_e500_subreg0_2_be"
  [(set (match_operand:SI 0 "int_reg_or_mem_operand" "=r,m")
(subreg:SI (match_operand:SPE64TF 1 "gpc_reg_operand" "+r,") 0))]
  "WORDS_BIG_ENDIAN
   && ((TARGET_E500_DOUBLE && (mode == DFmode || mode == TFmode))
   || (TARGET_SPE && mode != DFmode && mode != TFmode))"
  "@
   evmergelohi %0,%1,%1
   evmergelohi %1,%1,%1\;stw%U0%X0 %1,%0"
  [(set_attr "length" "4,8")])

After IRA, we have the following rtl dump results, with pseudo 192 not getting
a color and pseudo 283 getting assigned to the CTR (hard reg 66 ...ick!):

(insn 223 222 51 2 (set (reg/v:DF 192 [ tD.1744 ])
(mem/u/c:DF (reg/f:SI 339) [1  S8 A64])) "q.i":28 2031
{*movdf_e500_double}
 (expr_list:REG_DEAD (reg/f:SI 339)
(expr_list:REG_EQUIV (const_double:DF 0.0 [0x0.0p+0])
(nil
...
(insn 113 97 234 2 (set (reg:SI 283)
(subreg:SI (reg/v:DF 192 [ tD.1744 ]) 0)) "q.i":9 1975
{*mov_sidf_e500_subreg0_2_be}
 (nil))
...
(insn 111 107 116 2 (set (reg:DF 278)
(mult:DF (reg/v:DF 192 [ tD.1744 ])
(reg:DF 279))) "q.i":28 2038 {spe_muldf3}
 (expr_list:REG_DEAD (reg:DF 279)
(expr_list:REG_DEAD (reg/v:DF 192 [ tD.1744 ])
(nil

In lra-constraints.c:check_and_process_move() with curr_insn == insn 113, we
end up modifying insn 113 and emitting an insn before 113 that looks like:

(insn 273 97 113 2 (set (reg:SI 345)
(subreg:SI (reg/v:DF 192 [ t ]) 0)) "q.i":9 1975
{*mov_sidf_e500_subreg0_2_be}
 (nil))

(insn 113 273 234 2 (set (reg:SI 283)
(reg:SI 345)) "q.i":9 1975 {*mov_sidf_e500_subreg0_2_be}
 (nil))

Notice that the new insn 273 looks just like the old insn 113 and now insn 113
is invalid since this is a SImode reg to SImode reg copy without the subreg
which won't match the mov_sidf_e500_subreg0_2_be pattern, which leads us to
SEGV during check_rtl()'s call to constrain_operands() via
extract_constrain_insn().

The invalid insn 113 modification occurs due to the following code near the
bottom of check_and_process_move():

  if (new_reg != NULL_RTX)
SET_SRC (curr_insn_set) = new_reg;

In this case, new_reg was created by:

  if (secondary_class != NO_REGS)
new_reg = lra_create_new_reg_with_unique_value (GET_MODE (src), NULL_RTX,
secondary_class,
"secondary");

where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI (reg:DF
...) which doesn't seem correct.

Vlad, should we have never got this far into check_and_process_move() with this
type of insn?  Adding an ugly hack that creates an early out for this insn (ie,
set (reg:SI) (subreg:SI (reg:DF))) seems to make us compile.

If we are supposed to still process this insn, then how about something like
the following patch that creates a new_reg with the mode of the src register
and not the subreg and then replacing that instead of the entire subreg src? 
This too eliminates the SEGV/ICE.

Joseph, in the mean time, can you try the patch below to see if you get farther
into your glibc build?

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 243444)
+++ lra-constraints.c   (working copy)
@@ -1237,12 +1237,12 @@ check_and_process_move (bool *change_p,
   *change_p = true;
   new_reg = NULL_RTX;
   if (secondary_class != NO_REGS)
-new_reg = lra_create_new_reg_with_unique_value (GET_MODE (src), NULL_RTX,
+new_reg = lra_create_new_reg_with_unique_value (GET_MODE (sreg), NULL_RTX,
secondary_class,
"secondary");
   start_sequence ();
   if (sri.icode == CODE_FOR_nothing)
-lra_emit_move (new_reg, src);
+lra_emit_move (new_reg, sreg);
   else
 {
   enum reg_class scratch_class;
@@ -1259,7 +1259,12 @@ check_and_process_move (bool *change_p,
   end_sequence ();
   lra_process_new_insns (curr_insn, before, NULL, "Inserting the move");
   if (new_reg != NULL_RTX)
-SET_SRC (curr_insn_set) = new_reg;
+{
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}
   else
 {
   if (lra_dump_file != NULL)

DWARF output different between GCC 5 and 6

[Tom O'Connor]

Hello,

I've observed a difference in DWARF output for the same input source code 
between GCC 5 and GCC 6, specifically in the DW_AT_data_member_location values 
for bitfield members of structs. For example,

s.c:
struct s {
  unsigned int shutdown:2,
no_check_tx:1,
no_check_rx:1,
userlocks:4,
protocol:8,
type:16;
};

int main() {
  struct s s;
  return 0;
}


GCC 5 reports DW_AT_data_member_location for all the fields as 0, which is 
expected.
GCC 6 reports DW_AT_data_member_location for the "type" and "protocol" fields 
as 2 and 1 respectively, all other fields 0 as expected. The DW_AT_bt_offset 
fields for "type" and "protocol" change as well.

Am I wrong to expect that for the given struct above, that the member location 
offset for all fields should be 0 across both compilers?

GCC 5.4.0 readelf --debug-dump:

 <2><64>: Abbrev Number: 3 (DW_TAG_member)
<65>   DW_AT_name: (indirect string, offset: 0x0): userlocks
<69>   DW_AT_decl_file   : 1
<6a>   DW_AT_decl_line   : 5
<6b>   DW_AT_type: <0x92>   
<6f>   DW_AT_byte_size   : 4
<70>   DW_AT_bit_size: 4
<71>   DW_AT_bit_offset  : 24   
<72>   DW_AT_data_member_location: 0
 <2><73>: Abbrev Number: 3 (DW_TAG_member)
<74>   DW_AT_name: (indirect string, offset: 0x1c): protocol
<78>   DW_AT_decl_file   : 1
<79>   DW_AT_decl_line   : 6
<7a>   DW_AT_type: <0x92>   
<7e>   DW_AT_byte_size   : 4
<7f>   DW_AT_bit_size: 8
<80>   DW_AT_bit_offset  : 16   
<81>   DW_AT_data_member_location: 0
 <2><82>: Abbrev Number: 3 (DW_TAG_member)
<83>   DW_AT_name: (indirect string, offset: 0x17): type
<87>   DW_AT_decl_file   : 1
<88>   DW_AT_decl_line   : 7
<89>   DW_AT_type: <0x92>   
<8d>   DW_AT_byte_size   : 4
<8e>   DW_AT_bit_size: 16   
<8f>   DW_AT_bit_offset  : 0
<90>   DW_AT_data_member_location: 0


GCC 6.1.0 readelf --debug-dump:

 <2><64>: Abbrev Number: 3 (DW_TAG_member)
<65>   DW_AT_name: (indirect string, offset: 0x0): userlocks
<69>   DW_AT_decl_file   : 1
<6a>   DW_AT_decl_line   : 5
<6b>   DW_AT_type: <0x92>   
<6f>   DW_AT_byte_size   : 4
<70>   DW_AT_bit_size: 4
<71>   DW_AT_bit_offset  : 24   
<72>   DW_AT_data_member_location: 0
 <2><73>: Abbrev Number: 3 (DW_TAG_member)
<74>   DW_AT_name: (indirect string, offset: 0x4a): protocol
<78>   DW_AT_decl_file   : 1
<79>   DW_AT_decl_line   : 6
<7a>   DW_AT_type: <0x92>   
<7e>   DW_AT_byte_size   : 4
<7f>   DW_AT_bit_size: 8
<80>   DW_AT_bit_offset  : 24   
<81>   DW_AT_data_member_location: 1
 <2><82>: Abbrev Number: 3 (DW_TAG_member)
<83>   DW_AT_name: (indirect string, offset: 0x17): type
<87>   DW_AT_decl_file   : 1
<88>   DW_AT_decl_line   : 7
<89>   DW_AT_type: <0x92>   
<8d>   DW_AT_byte_size   : 4
<8e>   DW_AT_bit_size: 16   
<8f>   DW_AT_bit_offset  : 16   
<90>   DW_AT_data_member_location: 2

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|FIXED   |---

--- Comment #6 from Dominique d'Humieres  ---
The test in comment 0 is still giving an off by 1 result (7.0 at r243758):

 Call with array slice: off by 1
 Inside LCB: size is4
 Show: f12.
 Show: f13.
 Show: f14.
 Show: f10.

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||6.2.0, 7.0
 Resolution|--- |FIXED
   Target Milestone|--- |6.2
  Known to fail||4.9.0, 5.4.1

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to physiker from comment #4)
> When I use gfortran version 7 to compile the code listed in comment 3,
> executing the resulting binary yields the following output:
> 
> ./pr56691 
>  Values in work are:
>1.   2.   3.   4.
>  Call with whole array: works fine
>  Inside LCB: size is4
>1.   2.   3.   4.
>  Call with array slice: off by 1
>  Inside LCB: size is4
>1.   2.   3.   4.
> 
> This is the expected result. The bug might be fixed.

Confirmed. In fact I see it working already in 6.2. It can definitely be
closed.

Go patch committed: pass function to all backend methods that create statements

[Ian Lance Taylor]

This patch by Than McIntosh to the Go frontend changes the backend
interface to pass the function to all the methods that create
statements.  Having the function available simplifies things if a
temporary variable has to be created during the construction of a
statement.

This also includes a change to the Mark_lvalue_varexprs helper class
to handle indirections on the left hand side of assignments (e.g.
"*x.y = ...").

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian

2016-12-16  Than McIntosh  

* go-gcc.cc (Gcc_backend::expression_statement): Add Bfunction*
parameter.
(Gcc_backend::init_statement): Likewise.
(Gcc_backend::assignment_statement): Likewise.
(Gcc_backend::if_statement): Likewise.
Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc(revision 243321)
+++ gcc/go/go-gcc.cc(working copy)
@@ -361,21 +361,22 @@ class Gcc_backend : public Backend
   { return this->make_statement(error_mark_node); }
 
   Bstatement*
-  expression_statement(Bexpression*);
+  expression_statement(Bfunction*, Bexpression*);
 
   Bstatement*
-  init_statement(Bvariable* var, Bexpression* init);
+  init_statement(Bfunction*, Bvariable* var, Bexpression* init);
 
   Bstatement*
-  assignment_statement(Bexpression* lhs, Bexpression* rhs, Location);
+  assignment_statement(Bfunction*, Bexpression* lhs, Bexpression* rhs,
+  Location);
 
   Bstatement*
   return_statement(Bfunction*, const std::vector&,
   Location);
 
   Bstatement*
-  if_statement(Bexpression* condition, Bblock* then_block, Bblock* else_block,
-  Location);
+  if_statement(Bfunction*, Bexpression* condition, Bblock* then_block,
+  Bblock* else_block, Location);
 
   Bstatement*
   switch_statement(Bfunction* function, Bexpression* value,
@@ -1972,7 +1973,7 @@ Gcc_backend::stack_allocation_expression
 // An expression as a statement.
 
 Bstatement*
-Gcc_backend::expression_statement(Bexpression* expr)
+Gcc_backend::expression_statement(Bfunction*, Bexpression* expr)
 {
   return this->make_statement(expr->get_tree());
 }
@@ -1980,7 +1981,7 @@ Gcc_backend::expression_statement(Bexpre
 // Variable initialization.
 
 Bstatement*
-Gcc_backend::init_statement(Bvariable* var, Bexpression* init)
+Gcc_backend::init_statement(Bfunction*, Bvariable* var, Bexpression* init)
 {
   tree var_tree = var->get_decl();
   tree init_tree = init->get_tree();
@@ -2013,8 +2014,8 @@ Gcc_backend::init_statement(Bvariable* v
 // Assignment.
 
 Bstatement*
-Gcc_backend::assignment_statement(Bexpression* lhs, Bexpression* rhs,
- Location location)
+Gcc_backend::assignment_statement(Bfunction* bfn, Bexpression* lhs,
+ Bexpression* rhs, Location location)
 {
   tree lhs_tree = lhs->get_tree();
   tree rhs_tree = rhs->get_tree();
@@ -2029,8 +2030,8 @@ Gcc_backend::assignment_statement(Bexpre
   // anything anyhow.
   if (int_size_in_bytes(TREE_TYPE(lhs_tree)) == 0
   || int_size_in_bytes(TREE_TYPE(rhs_tree)) == 0)
-return this->compound_statement(this->expression_statement(lhs),
-   this->expression_statement(rhs));
+return this->compound_statement(this->expression_statement(bfn, lhs),
+   this->expression_statement(bfn, rhs));
 
   // Sometimes the same unnamed Go type can be created multiple times
   // and thus have multiple tree representations.  Make sure this does
@@ -2194,8 +2195,9 @@ Gcc_backend::exception_handler_statement
 // If.
 
 Bstatement*
-Gcc_backend::if_statement(Bexpression* condition, Bblock* then_block,
- Bblock* else_block, Location location)
+Gcc_backend::if_statement(Bfunction*, Bexpression* condition,
+ Bblock* then_block, Bblock* else_block,
+ Location location)
 {
   tree cond_tree = condition->get_tree();
   tree then_tree = then_block->get_tree();
@@ -2700,8 +2702,9 @@ Gcc_backend::temporary_variable(Bfunctio
   // Don't initialize VAR with BINIT, but still evaluate BINIT for
   // its side effects.
   if (this->type_size(btype) == 0 && init_tree != NULL_TREE)
-*pstatement = this->compound_statement(this->expression_statement(binit),
-  *pstatement);
+*pstatement =
+  this->compound_statement(this->expression_statement(function, binit),
+  *pstatement);
 
   return new Bvariable(var);
 }
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243735)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-310862eb11ec0705f21a375c0dd16f46a8d901c1
+e6fb629c5b246bceab5fc8e8613cf2cf82b1e98f
 
 The first line of this file holds the git revision number of the last
 merge done from the 

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661

--- Comment #5 from janus at gcc dot gnu.org ---
Btw, this variant is wrongly rejected:


MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
  END TYPE
CONTAINS
  SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
WRITE (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  Class(t), allocatable :: x
  NAMELIST /nml/ x
  x = t('a')
  WRITE (*, nml)
END



   NAMELIST /nml/ x
   1
Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and requires
a defined input/output procedure

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661

--- Comment #4 from janus at gcc dot gnu.org ---
I think this should fix it:


Index: libgfortran/io/write.c
===
--- libgfortran/io/write.c  (revision 243729)
+++ libgfortran/io/write.c  (working copy)
@@ -2076,7 +2076,7 @@ nml_write_obj (st_parameter_dt *dtp, namelist_info
   /* Write namelist variable names in upper case. If a derived type,
  nothing is output.  If a component, base and base_name are set.  */

-  if (obj->type != BT_DERIVED)
+  if (obj->type != BT_DERIVED || obj->dtio_sub != NULL)
 {
   namelist_write_newline (dtp);
   write_character (dtp, " ", 1, 1, NODELIM);
@@ -2253,7 +2253,7 @@ nml_write_obj (st_parameter_dt *dtp, namelist_info
  child_iomsg = tmp_iomsg;
  child_iomsg_len = IOMSG_LEN;
}
- namelist_write_newline (dtp);
+
  /* Call the user defined formatted WRITE procedure.  */
  dtp->u.p.current_unit->child_dtio++;
  dtio_ptr ((void *)_obj, , iotype, ,

[Bug rtl-optimization/78580] [6/7 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #2)
>
> So, is the bug that i?86 needs Q_REGS to be an allocno class always (shall
> ix86_additional_allocno_class_p return true also for Q_REGS?  Just for -m32
> or always?), or is the bug that if Q_REGS is not an allocno class then there
> shouldn't be allocno with that class?

I believe there should be no allocno having reg class which is not an allocno
class.

I've been working on the issue for some time but still did not find the best
way and place (there are a few of them) to fix it especially when the target
code can change allocno class using a hook.

I am planning to have a patch on the next week.

[Bug middle-end/78837] New: missing -Walloca-larger-than on a call in a ternary expression

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78837

Bug ID: 78837
   Summary: missing -Walloca-larger-than on a call in a ternary
expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Both -Walloca-larger-than and -Walloc-larger-than fail to diagnose calls where
the called function is the result of a ternary operator, as in (n < 123 ?
alloca : malloc)(n): 

$ cat d.c && gcc -O2 -S -Walloca-larger-than=10 -Walloc-size-larger-than=10 d.c
void f0 (void*);

void f1 (unsigned n)
{
  void *p;

  if (n < 32)
n = 32;

  if (n < 123)
p = __builtin_alloca (n);
  else
p = __builtin_malloc (n);

  f0 (p);
}

void f2 (unsigned n)
{
  if (n < 32)
n = 32;

  void *p = (123 < n ? __builtin_malloc: __builtin_alloca)(n);   // missing
warning
  f0 (p);
}
d.c: In function ‘f1’:
d.c:11:7: warning: argument to ‘alloca’ may be too large
[-Walloca-larger-than=]
 p = __builtin_alloca (n);
 ~~^~
d.c:11:7: note: limit is 10 bytes, but argument may be as large as 122
d.c:13:7: warning: argument 1 range [32, 4294967295] exceeds maximum object
size 10 [-Walloc-size-larger-than=]
 p = __builtin_malloc (n);
 ~~^~
d.c:13:7: note: in a call to built-in allocation function ‘__builtin_malloc’

[Bug fortran/78661] [F03] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661

--- Comment #3 from janus at gcc dot gnu.org ---
Reduced test case:

MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
  END TYPE
CONTAINS
  SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
WRITE (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  TYPE(t) :: x
  NAMELIST /nml/ x
  x = t('a')
  WRITE (*, nml)
END

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

[physiker at toast2 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

physiker at toast2 dot net changed:

   What|Removed |Added

 CC||physiker at toast2 dot net

--- Comment #4 from physiker at toast2 dot net ---
When I use gfortran version 7 to compile the code listed in comment 3,
executing the resulting binary yields the following output:

./pr56691 
 Values in work are:
   1.   2.   3.   4.
 Call with whole array: works fine
 Inside LCB: size is4
   1.   2.   3.   4.
 Call with array slice: off by 1
 Inside LCB: size is4
   1.   2.   3.   4.

This is the expected result. The bug might be fixed.

LANG=C gfortran-7 -o pr56691 pr56691.f90 -v -W -Wall
Driving: gfortran-7 -o pr56691 pr56691.f90 -v -W -Wall
-mmacosx-version-min=10.11.6 -asm_macosx_version_min=10.11 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-7
Thread model: posix
gcc version 7.0.0 20161215 (experimental) [trunk revision 243680] (GCC) 
COLLECT_GCC_OPTIONS='-o' 'pr56691' '-v' '-Wextra' '-Wall'
'-mmacosx-version-min=10.11.6' '-asm_macosx_version_min=10.11' '-shared-libgcc'
'-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951 pr56691.f90 -fPIC
-quiet -dumpbase pr56691.f90 -mmacosx-version-min=10.11.6 -mtune=core2 -auxbase
pr56691 -Wextra -Wall -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccv54gNH.s
GNU Fortran (GCC) version 7.0.0 20161215 (experimental) [trunk revision 243680]
(x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 7.0.0 20161215 (experimental) [trunk revision
243680] (x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-o' 'pr56691' '-v' '-Wextra' '-Wall'
'-mmacosx-version-min=10.11.6'  '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.11 -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSNEf1F.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccv54gNH.s
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx10.11.0 -filetype obj -main-file-name ccv54gNH.s -target-cpu
core2 -fdebug-compilation-dir /Users/Peter/Devel/f90 -dwarf-debug-producer
Apple LLVM version 8.0.0 (clang-800.0.42.1) -dwarf-version=2 -mrelocation-model
pic -o /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSNEf1F.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccv54gNH.s
Reading specs from
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-o' 'pr56691' '-v' '-Wextra' '-Wall'
'-mmacosx-version-min=10.11.6'  '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/:/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/../../../
COLLECT_GCC_OPTIONS='-o' 'pr56691' '-v' '-Wextra' '-Wall'
'-mmacosx-version-min=10.11.6'  '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.11.6 -weak_reference_mismatches non-weak -o
pr56691 -L/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSNEf1F.o -lgfortran
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 7.0.0 20161215 (experimental) [trunk revision 243680]
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.11.6

[Bug ada/62122] GNAT RM: flaw in example of @node Attribute Unrestricted_Access

[georggcc at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62122

--- Comment #2 from Georg  ---
Created attachment 40352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40352=edit
changes to example in GNAT RM section on Unrestricted_Access

Since variable Global needs initialization, I have added an access
value pointing to a new  procedure. For the latter, I have chosen a
most unrestricted procedure, null, which seemed fitting. This
preserves the null exclusion of the subprogram pointer type.

[Bug c++/71972] [6 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71972

Jakub Jelinek  changed:

   What|Removed |Added

 CC||gcc at tnix dot eu

--- Comment #8 from Jakub Jelinek  ---
*** Bug 71229 has been marked as a duplicate of this bug. ***

[Bug c++/71229] internal compiler error: Segmentation fault, when copying an array in a constexpr function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71229

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jakub Jelinek  ---
Yeah, this got fixed with r238729 on the trunk.

*** This bug has been marked as a duplicate of bug 71972 ***

[Bug c++/71226] [C++14] ICE in fold_binary_loc, at fold-const.c:9252, from constexpr function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71226

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Jakub Jelinek  ---
Yeah, this got fixed with r238729 on the trunk.

*** This bug has been marked as a duplicate of bug 71972 ***

[Bug c++/71972] [6 Regression] ICE with "-std=c++14" on x86_64-linux-gnu (internal compiler error: Segmentation fault, cxx_eval_store_expression)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71972

Jakub Jelinek  changed:

   What|Removed |Added

 CC||gccbug at kundor dot org

--- Comment #7 from Jakub Jelinek  ---
*** Bug 71226 has been marked as a duplicate of this bug. ***

[Bug preprocessor/78836] New: ICE in get_source_location_for_substring, at input.c:1461

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78836

Bug ID: 78836
   Summary: ICE in get_source_location_for_substring, at
input.c:1461
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With some local changes to the gimple-ssa-sprintf.c pass I'm intermittently
seeing the following ICE.  It only shows up every few runs of the compiler and
is sensitive to things like its pathname.  It doesn't seem to be reproducible
in GDB and Valgrind doesn't report anything.  I'll see if I can reduce it to a
test case independent of my local changes, or maybe build a sanitized GCC.  I
report now in case the problem jumps out at you David (or someone else familiar
with this area).

$ /home/msebor/build/gcc-78703/gcc/xgcc -B/home/msebor/build/gcc-78703/gcc -S
-Wformat -Wformat-length=1 ice.c
...
ice.c:85:6: internal compiler error: in get_source_location_for_substring, at
input.c:1461
 void test_sprintf_c_const (void)
  ^~~~
0x1a1f144 get_source_location_for_substring(cpp_reader*, string_concat_db*,
unsigned int, cpp_ttype, int, int, int, unsigned int*)
/src/gcc/78703/gcc/input.c:1461
0x8496bd c_get_substring_location(substring_loc const&, unsigned int*)
/src/gcc/78703/gcc/c-family/c-common.c:865
0xed797b substring_loc::get_location(unsigned int*) const
/src/gcc/78703/gcc/substring-locations.c:194
0xed7667 format_warning_va(substring_loc const&, source_range const*, char
const*, int, char const*, __va_list_tag (*) [1])
/src/gcc/78703/gcc/substring-locations.c:112
0xed792a format_warning_at_substring(substring_loc const&, source_range const*,
char const*, int, char const*, ...)
/src/gcc/78703/gcc/substring-locations.c:179
0x18c83cb add_bytes
/src/gcc/78703/gcc/gimple-ssa-sprintf.c:2268
0x18c914b compute_format_length
/src/gcc/78703/gcc/gimple-ssa-sprintf.c:2694
0x18ca0fc handle_gimple_call
/src/gcc/78703/gcc/gimple-ssa-sprintf.c:3071
0x18ca1cd execute
/src/gcc/78703/gcc/gimple-ssa-sprintf.c:3099
Please submit a full bug report,
with preprocessed source if appropriate.

[PATCH] Fix -fcompare-debug sanopt bug (PR sanitizer/78832)

[Jakub Jelinek]

Hi!

The following testcase fails with -fcompare-debug, because we have a bb
containing 2 ASAN_MARK (POISON, ...) calls immediately after each other,
followed with -g only by debug stmts till end of basic block.
sanitize_asan_mark_poison walks stmts in a bb backwards and assumes
(incorrectly) that gsi_remove will move the iterator backwards too, but
it moves it forward (and if removing stmt at the end of bb turns it into
gsi end).  The effect is that with -g, we remove both ASAN_MARK calls
(desirable), because after the first removal gsi is moved to the following
debug stmt which we do nothing about once again and get to the first
ASAN_MARK, but with -g0 gsi becomes end and we don't remove anything further
from the bb after removing the last stmt.

Fixed by copying the iterator to a copy, gsi_prev and then gsi_remove on the
copy.  The rest is just cleanup, I think we don't need the bool vars when we
can easily continue; instead.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-12-16  Jakub Jelinek  

PR sanitizer/78832
* sanopt.c (sanitize_asan_mark_unpoison): Remove next variable, use
continue if gsi_next should be skipped.
(sanitize_asan_mark_poison): Remove prev variable, use continue if
gsi_prev should be skipped.  When removing ASAN_MARK, do gsi_prev
first and gsi_remove on a previously made copy of the iterator.

* gcc.dg/asan/pr78832.c: New test.

--- gcc/sanopt.c.jj 2016-12-14 20:28:14.0 +0100
+++ gcc/sanopt.c2016-12-16 17:08:03.016432304 +0100
@@ -740,7 +740,6 @@ sanitize_asan_mark_unpoison (void)
   gimple_stmt_iterator gsi;
   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
{
- bool next = true;
  gimple *stmt = gsi_stmt (gsi);
  if (gimple_call_internal_p (stmt, IFN_ASAN_MARK))
{
@@ -753,12 +752,11 @@ sanitize_asan_mark_unpoison (void)
  unlink_stmt_vdef (stmt);
  release_defs (stmt);
  gsi_remove (, true);
- next = false;
+ continue;
}
}
 
- if (next)
-   gsi_next ();
+ gsi_next ();
}
 }
 }
@@ -840,7 +838,6 @@ sanitize_asan_mark_poison (void)
   gimple_stmt_iterator gsi;
   for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi);)
{
- bool prev = true;
  gimple *stmt = gsi_stmt (gsi);
  if (maybe_contains_asan_check (stmt))
break;
@@ -850,12 +847,13 @@ sanitize_asan_mark_poison (void)
fprintf (dump_file, "Removing ASAN_MARK poison\n");
  unlink_stmt_vdef (stmt);
  release_defs (stmt);
- gsi_remove (, true);
- prev = false;
+ gimple_stmt_iterator gsi2 = gsi;
+ gsi_prev ();
+ gsi_remove (, true);
+ continue;
}
 
- if (prev)
-   gsi_prev ();
+ gsi_prev ();
}
 }
 }
--- gcc/testsuite/gcc.dg/asan/pr78832.c.jj  2016-12-16 17:22:27.446280214 
+0100
+++ gcc/testsuite/gcc.dg/asan/pr78832.c 2016-12-16 17:23:17.117638783 +0100
@@ -0,0 +1,22 @@
+/* PR sanitizer/78832 */
+/* { dg-do compile } */
+/* { dg-additional-options "-fcompare-debug" } */
+
+void bar (int *);
+
+int
+foo (int x)
+{
+  int *f = 0;
+  if (x)
+goto lab;
+  {
+int y, z;
+bar ();
+int *d = 
+bar ();
+int *e = 
+  }
+  f = 
+  lab: return 6;
+}

Jakub

[Bug c++/71226] [C++14] ICE in fold_binary_loc, at fold-const.c:9252, from constexpr function

[gccbug at kundor dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71226

--- Comment #4 from Nick Matteo  ---
Appears to be fixed in GCC 6.2.0.

[PATCH] varasm: Propagate litpool decl alignment to generated RTX.

[Andreas Krebbel]

When pushing a value into the literal pool the resulting decl might
get a higher alignment than the original expression depending on how a
target defines CONSTANT_ALIGNMENT.  Generating an RTX for the constant
pool access we currently use the alignment from the original
expression.  Changed with the attached patch.

This fixes a GCC 6 regression for S/390.  For arrays of string
constants as in the attached testcase encode_section_info is not able
to figure out that the constant pool slot is already properly aligned
since the mem_align field in the rtx is not set properly.

Another question is why (at the end of build_constant_desc) we invoke
the encode_section_info hook with the original expression instead of
the newly generated var_decl?  I think the hook is supposed to be
invoked with a decl?!

  /* Set flags or add text to the name to record information, such as
 that it is a local symbol.  If the name is changed, the macro
 ASM_OUTPUT_LABELREF will have to know how to strip this
 information.  This call might invalidate our local variable
 SYMBOL; we can't use it afterward.  */
  targetm.encode_section_info (exp, rtl, true);

  desc->rtl = rtl;

  return desc;
}

Bootstrapped and regtested on x86_64 and s390x.

No regressions.

Ok?

-Andreas-

gcc/ChangeLog:

2016-12-16  Andreas Krebbel  

* varasm.c (build_constant_desc): Use the alignment of the var
decl instead of the original expression.

gcc/testsuite/ChangeLog:

2016-12-16  Andreas Krebbel  

* gcc.target/s390/litpool-str-1.c: New test.
---
 gcc/testsuite/gcc.target/s390/litpool-str-1.c | 22 ++
 gcc/varasm.c  |  4 
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/litpool-str-1.c

diff --git a/gcc/testsuite/gcc.target/s390/litpool-str-1.c 
b/gcc/testsuite/gcc.target/s390/litpool-str-1.c
new file mode 100644
index 000..cd921d2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/litpool-str-1.c
@@ -0,0 +1,22 @@
+/* Make sure strings are recognized as being accessible through larl.
+   This requires the symbol ref alignment properly propagated to
+   encode_section_info.  */
+
+/* { dg-do compile } */
+/* { dg-options "-march=z900 -O2 -fpic" } */
+
+
+extern void foo(const char*, const char*, const char*);
+
+void bar(int i)
+{
+  const char t1[10] = "test";
+  const char t2[10] = "test2";
+  const char t3[2][10] = {
+   "foofoofoo",
+   "barbarbar",
+};
+  foo(t1, t2, t3[i]);
+}
+
+/* { dg-final { scan-assembler-not "GOTOFF" } } */
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 5b15847..68a7ba2 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -3296,6 +3296,10 @@ build_constant_desc (tree exp)
   set_mem_attributes (rtl, exp, 1);
   set_mem_alias_set (rtl, 0);
 
+  /* Putting EXP into the literal pool might have imposed a larger
+ alignment which should be visible in the RTX as well.  */
+  set_mem_align (rtl, DECL_ALIGN (decl));
+
   /* We cannot share RTX'es in pool entries.
  Mark this piece of RTL as required for unsharing.  */
   RTX_FLAG (rtl, used) = 1;
-- 
2.9.1

[Bug middle-end/78622] [7 Regression] -Wformat-length/-fprintf-return-value incorrect with overflow/wrapping

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78622

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Dec 16 20:27:51 2016
New Revision: 243765

URL: https://gcc.gnu.org/viewcvs?rev=243765=gcc=rev
Log:
2016-12-16  Jerry DeLisle  

PR fortran/78622
* io.c (format_lex): Continue of string delimiter seen.

* io/transfer.c (get_dt_format): New static function to alloc
and set the DT iotype string, handling doubled quotes.
(formatted_transfer_scalar_read,
formatted_transfer_scalar_write): Use new function.

* gfortran.dg/dtio_20.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_20.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

Re: Fix for libstdc++-v3's error_constants.h for MinGW-W64

[Jonathan Wakely]

On 16/12/16 16:28 +0300, niXman wrote:

Jonathan Wakely 2016-12-16 16:04:


I don't think this is suitable for the branches, but could be applied
to trunk (as the patch was posted during stage 1, but I missed it).

Ok.


Does this require a particular version of MinGW-w64?

Yes, at the moment MinGW-W64 trunk is required. (MinGW-W64-v6)


Does it work for older versions?

No.


OK, how about this instead then?

This unconditionally enables all the error codes supported by
mingw-w64 v5, and uses configure checks to detect the ones that are
only available on trunk. This means it will still work for v5, but if
you use trunk you get them all.

Could you test this please?


commit 0ed1d7de154ece96733edd693caeb84cfa5f4a78
Author: Jonathan Wakely 
Date:   Fri Dec 16 20:21:40 2016 +

PR71444 define more error constants for mingw-w64

	PR libstdc++/71444
	* config/os/mingw32-w64/error_constants.h
	(address_family_not_supported, address_in_use, address_not_available)
	(already_connected, connection_aborted, connection_already_in_progress)
	connection_refused, connection_reset, cross_device_link)
	(destination_address_required, host_unreachable, message_size)
	(network_down, network_reset, network_unreachable, no_buffer_space)
	(no_protocol_option, not_a_socket, not_connected, operation_canceled)
	(operation_in_progress, operation_not_supported, protocol_error)
	(protocol_not_supported, too_many_links, too_many_symbolic_link_levels)
	(value_too_large, wrong_protocol_type): Define.
	(bad_message, identifier_removed, no_link, no_message_available)
	(no_message, no_stream_resources, not_a_stream, owner_dead)
	(state_not_recoverable, stream_timeout, text_file_busy): Define
	conditionally.

diff --git a/libstdc++-v3/config/os/mingw32-w64/error_constants.h b/libstdc++-v3/config/os/mingw32-w64/error_constants.h
index 5cbf63c..950f6e7 100644
--- a/libstdc++-v3/config/os/mingw32-w64/error_constants.h
+++ b/libstdc++-v3/config/os/mingw32-w64/error_constants.h
@@ -41,22 +41,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 // replaced by Winsock WSA-prefixed equivalents.
   enum class errc
 {
-//address_family_not_supported = 		EAFNOSUPPORT,
-//address_in_use = EADDRINUSE,
-//address_not_available = 			EADDRNOTAVAIL,
-//already_connected = 			EISCONN,
+  address_family_not_supported = 		EAFNOSUPPORT,
+  address_in_use = EADDRINUSE,
+  address_not_available = 			EADDRNOTAVAIL,
+  already_connected = 			EISCONN,
   argument_list_too_long = 			E2BIG,
   argument_out_of_domain = 			EDOM,
   bad_address = EFAULT,
   bad_file_descriptor = 			EBADF,
-//bad_message = EBADMSG,
+#ifdef _GLIBCXX_HAVE_EBADMSG
+  bad_message = EBADMSG,
+#endif
   broken_pipe = EPIPE,
-//connection_aborted = 			ECONNABORTED,
-//connection_already_in_progress = 		EALREADY,
-//connection_refused = 			ECONNREFUSED,
-//connection_reset = 			ECONNRESET,
-//cross_device_link = 			EXDEV,
-//destination_address_required = 		EDESTADDRREQ,
+  connection_aborted = 			ECONNABORTED,
+  connection_already_in_progress = 		EALREADY,
+  connection_refused = 			ECONNREFUSED,
+  connection_reset = 			ECONNRESET,
+  cross_device_link = 			EXDEV,
+  destination_address_required = 		EDESTADDRREQ,
   device_or_resource_busy = 		EBUSY,
   directory_not_empty = 			ENOTEMPTY,
   executable_format_error = 		ENOEXEC,
@@ -64,8 +66,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   file_too_large = EFBIG,
   filename_too_long = 			ENAMETOOLONG,
   function_not_supported = 			ENOSYS,
-//host_unreachable = 			EHOSTUNREACH,
-//identifier_removed = 			EIDRM,
+  host_unreachable = 			EHOSTUNREACH,
+#ifdef _GLIBCXX_HAVE_EIDRM
+  identifier_removed = 			EIDRM,
+#endif
   illegal_byte_sequence = 			EILSEQ,
   inappropriate_io_control_operation = 	ENOTTY,
   interrupted = EINTR,
@@ -73,67 +77,84 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   invalid_seek = ESPIPE,
   io_error = EIO,
   is_a_directory = EISDIR,
-//message_size = EMSGSIZE,
-//network_down = ENETDOWN,
-//network_reset = ENETRESET,
-//network_unreachable = 			ENETUNREACH,
-//no_buffer_space = 			ENOBUFS,
+  message_size = EMSGSIZE,
+  network_down = ENETDOWN,
+  network_reset = ENETRESET,
+  network_unreachable = 			ENETUNREACH,
+  no_buffer_space = 			ENOBUFS,
 #ifdef _GLIBCXX_HAVE_ECHILD
   no_child_process = 			ECHILD,
 #endif
-//no_link = ENOLINK,
+#ifdef _GLIBCXX_HAVE_ENOLINK
+  no_link = ENOLINK,
+#endif
   no_lock_available = 			ENOLCK,
-//no_message_available = 			ENODATA,
-//no_message = ENOMSG,
-//no_protocol_option = 			ENOPROTOOPT,
+#ifdef _GLIBCXX_HAVE_ENODATA
+  no_message_available = 			ENODATA,
+#endif
+#ifdef _GLIBCXX_HAVE_ENOMSG

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 01:01:13PM -0700, Jeff Law wrote:
> > Thanks.  Reduced to something like:
> > int
> > foo (const char *name)
> > {
> >   if (name)
> > return 6;
> >   return __builtin_strlen (name);
> > }
> > This is warned about both with Martin's late warning and my after ccp2
> > warning version.  We should include it in gcc testsuite.
> I'll note this is an example of a case where Andrew's work would likely help
> because it allows us to ask for a range of name_XX at the return statement
> and it'll give us back a range that is constrained by the path(s) which
> reach the return statement.
> 
> Contrast to the current VRP work where each SSA_NAME has a range, but that
> range must be valid for every context in which that SSA_NAME appears.

Well, inside the current VRP it has separate ranges for the different paths
and actually replaces the name in the strlen argument with NULL during evrp,
so doesn't suffer from the current VRP limitations.

Anyway, let's consider the warning from the linux kernel with the closedir,
I guess it can be simplified to something along the lines of:
void baz (char *) __attribute__((nonnull));
char *bar (int);

int
foo (void)
{
  char *p = bar (1);
  int ret = 0;
  if (p == 0)
{
  bar (2);
  bar (3);
  bar (4);
  ret = 1;
  goto out;
}
  bar (5);
  bar (6);
  bar (7);
  bar (8);
 out:
  baz (p);
  if (ret)
bar (10);
  return ret;
}

Here we jump thread it and with Martin's warning position warn, with
my patch don't warn.  But if the if (ret) bar (10); is removed, the
code has the same problem that on the error path p will be NULL, but it is
not going to be diagnosed.  For -Wmaybe-nonnull we could e.g. look at if
the argument is a PHI that has NULL at any of the edges; but that doesn't
cover the above case, because p has just one def and so there will be no
PHIs.

And yet another testcase:

void foo (const char *) __attribute__((nonnull));

void
bar (int x)
{
  foo (x ? (const char *) 0 : "");
}

Here we warn only with GCC 6 or with my patch, but not with current trunk,
so this case is a warning regression (if needed, I can split my patch into
smaller chunks, the part that addresses this is keeping the warning in the
FE and setting TREE_NO_WARNING if it warned, instead of not warning when
optimize in the FE at all).  Handling COND_EXPR in the argument might be
more -Wmaybe-nonnull thing though.  It isn't if you reach this source
location, there will be always UB, but if you reach this source location
along this and this path (and only careful analysis can discover if that
path is actually possible at runtime), then there will be UB.
Kind like we have -Wuninitialized and -Wmaybe-uninitialized.

Jakub

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jeff Law]

On 12/16/2016 11:40 AM, Jakub Jelinek wrote:

On Fri, Dec 16, 2016 at 07:29:13PM +0100, Markus Trippelsdorf wrote:

So, to be fair a gave Jakub's patch a try and it has exactly the same
issues for the Linux kernel: sometimes the warning only triggers with
-O3, e.g.:

 % cat sm_ftl.i
int a;
void mtd_read_oob(int);
void sm_read_sector(int *buffer) {
  __builtin_memset(buffer, 0, 1);
  mtd_read_oob(a);
}
void sm_get_zone() { sm_read_sector(0); }


In this case I think the warning is right, if you ever call sm_get_zone,
it will always invoke UB.

Agreed.




 % gcc -c -Wnonnull -O2 sm_ftl.i
 % gcc -c -Wnonnull -O3 sm_ftl.i
sm_ftl.i: In function ‘sm_get_zone’:
sm_ftl.i:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_memset(buffer, 0, 1);
   ^~
sm_ftl.i:4:3: note: in a call to built-in function ‘__builtin_memset’

Also, Jakub's patch doesn't catch the following case:

(tools/perf/util/trace-event-info.c from Linux)
//...
dir = opendir(path);
if (!dir) {
err = -errno;
pr_debug("can't read directory '%s'", path);
goto out;
}
//... other stuff
out:
closedir(dir);

Whereas Martin's does.


This is where you rely on jump threading to duplicate closedir,
otherwise you don't warn.  If you don't jump thread it (say there are
a few more statements after closedir that make it not worth it), then you
don't warn even late.
Right.  This is an inherent issue with path isolation (which is 
performed by jump threading and other passes).  Path isolation can 
easily expose constants that were previously hidden with two paths joined.


Propagation of those constants can then trigger this kind of warning. 
And I personally think that is a good thing.  It's precisely these kind 
of path specific failures that I want GCC to be catching -- because it's 
often hard for humans to see the error, particularly if there's a 
significant amount of visual space between the key points in the code.


And yes, it's lame that additional code before the closedir may hide the 
warning.  That's an artifact of the cost/benefit of path isolation.  But 
that already happens with a slew of our other warnings.  In an ideal 
world we'd have a stronger static analyzer that followed all the paths, 
but that's not where we are today.


I don't see that this kind of scenario inherently affecting the decision 
one way or the other -- it's more about frequency of false positives and 
mitigation in the false positive case in my mind.



jeff

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jeff Law]

On 12/16/2016 12:08 PM, Jakub Jelinek wrote:

On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote:

On Fri, 16 Dec 2016, Martin Sebor wrote:


I don't claim it can't be improved but it seems pretty good as
it is already.  Among the 6 instances it's found in GCC three
look like real bugs.


FWIW it's found at least one real bug in glibc
 - that's a case
where strlen is called on a pointer that can never be non-null if the
strlen call is reached.  (I don't know if there are other cases in glibc,
whether genuine bugs or false positives, that would appear later in the
build once that bug is fixed.)


Thanks.  Reduced to something like:
int
foo (const char *name)
{
  if (name)
return 6;
  return __builtin_strlen (name);
}
This is warned about both with Martin's late warning and my after ccp2
warning version.  We should include it in gcc testsuite.
I'll note this is an example of a case where Andrew's work would likely 
help because it allows us to ask for a range of name_XX at the return 
statement and it'll give us back a range that is constrained by the 
path(s) which reach the return statement.


Contrast to the current VRP work where each SSA_NAME has a range, but 
that range must be valid for every context in which that SSA_NAME appears.


jeff

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jeff Law]

On 12/16/2016 12:08 PM, Jakub Jelinek wrote:

On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote:

On Fri, 16 Dec 2016, Martin Sebor wrote:


I don't claim it can't be improved but it seems pretty good as
it is already.  Among the 6 instances it's found in GCC three
look like real bugs.


FWIW it's found at least one real bug in glibc
 - that's a case
where strlen is called on a pointer that can never be non-null if the
strlen call is reached.  (I don't know if there are other cases in glibc,
whether genuine bugs or false positives, that would appear later in the
build once that bug is fixed.)


Thanks.  Reduced to something like:
int
foo (const char *name)
{
  if (name)
return 6;
  return __builtin_strlen (name);
}
This is warned about both with Martin's late warning and my after ccp2
warning version.  We should include it in gcc testsuite.

Agreed.
jeff

Re: [patch,fortran] PR78622 [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

[Janne Blomqvist]

On Fri, Dec 16, 2016 at 4:16 AM, Jerry DeLisle  wrote:
> Hi all,
>
> The attached patch regression tested on x86-64-linux.
>
> This adds a static function to allocate and extract the DT format string
> that may contain doubled quotes.
>
> OK for trunk, test case also attched.

Ok, thanks.

>
> Jerry
>
> 2016-12-16  Jerry DeLisle  
>
> PR fortran/78622
> * io.c (format_lex): Continue of string delimiter seen.
>
> 2016-12-16  Jerry DeLisle  
>
> PR libgfortran/78622
> * io/transfer.c (get_dt_format): New static function to alloc
> and set the DT iotype string, handling doubled quotes.
> (formatted_transfer_scalar_read,
> formatted_transfer_scalar_write): Use new function.



-- 
Janne Blomqvist

[PATCH 1/2] print-rtl.c: use '<' and '>' rather than % for pseudos in compact mode

[David Malcolm]

On Fri, 2016-12-16 at 10:32 -0500, David Malcolm wrote:
> On Fri, 2016-12-16 at 14:28 +0100, Bernd Schmidt wrote:
> > On 12/14/2016 05:57 PM, David Malcolm wrote:
> > > Any preferences? (or other syntax ideas?).  My preference is one
> > > of
> > > the
> > > currently-unused sigils e.g. "@3", or to wrap them in braces
> > > "{3}".
> > 
> > Either might work, I'd vaguely prefer <3> over {3} but they're
> > equivalent really. Maybe using "@" is simplest if it's unused.
> 
> I mostly implemented @, but ran into an issue: it leads to lexer
> errors
> when parsing "__RTL"-tagged functions within cc1, where the lexer
> complains about the stray CPP_ATSIGN token:
> 
>   gcc.dg/rtl/aarch64/asr_div1.c:12:25: error: stray '@' in program
> 
> We could add a flag to the preprocessor to support this token when
> within c_parser_parse_rtl_body, but it seems simpler to just use a
> different syntax: '<3>'.  I'm working on the '<3>' syntax.
> 
> Dave

I've implemented the "(reg:SI <3>)" syntax, and created updates to the
remaining parts of the patch kit to use it.

Successfully built stage1 and ran the selftests for all 191 targets
in config-list.mk (for the combined patch kit) - so it looks like this
syntax works for all of our supported targets.

The following patch implements the change for print-rtl.c.

OK for trunk assuming it passes bootstrap?

gcc/ChangeLog:
* print-rtl.c (rtx_writer::print_rtx_operand_code_r): For
non-virtual pseudos in compact mode, wrap the regno in '<' and '>'
rather than using a '%' prefix.
* rtl-tests.c (selftest::test_dumping_regs): Update for above change.
---
 gcc/print-rtl.c | 8 
 gcc/rtl-tests.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index 77e6b05..d36589e 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -481,11 +481,11 @@ rtx_writer::print_rtx_operand_code_r (const_rtx in_rtx)
   fputc ('#', m_outfile);
 else if (m_compact)
   {
-   /* In compact mode, print pseudos with a '%' sigil following
-  by the regno, offset by (LAST_VIRTUAL_REGISTER + 1), so that the
-  first non-virtual pseudo is dumped as "%0".  */
+   /* In compact mode, print pseudos with '< and '>' wrapping the regno,
+  offseting it by (LAST_VIRTUAL_REGISTER + 1), so that the
+  first non-virtual pseudo is dumped as "<0>".  */
gcc_assert (regno > LAST_VIRTUAL_REGISTER);
-   fprintf (m_outfile, " %%%d", regno - (LAST_VIRTUAL_REGISTER + 1));
+   fprintf (m_outfile, " <%d>", regno - (LAST_VIRTUAL_REGISTER + 1));
   }
 else
   fprintf (m_outfile, " %d", regno);
diff --git a/gcc/rtl-tests.c b/gcc/rtl-tests.c
index bd918a7..07ceac7 100644
--- a/gcc/rtl-tests.c
+++ b/gcc/rtl-tests.c
@@ -104,9 +104,9 @@ test_dumping_regs ()
 }
 
   /* Test dumping of non-virtual pseudos.  */
-  ASSERT_RTL_DUMP_EQ ("(reg:SI %0)",
+  ASSERT_RTL_DUMP_EQ ("(reg:SI <0>)",
 gen_raw_REG (SImode, LAST_VIRTUAL_REGISTER + 1));
-  ASSERT_RTL_DUMP_EQ ("(reg:SI %1)",
+  ASSERT_RTL_DUMP_EQ ("(reg:SI <1>)",
 gen_raw_REG (SImode, LAST_VIRTUAL_REGISTER + 2));
 }
 
-- 
1.8.5.3

[PATCH 2/2] Changes to patch 8a to use <3> syntax

[David Malcolm]

For reference, here are the changes to patch 8a to update it to the
new syntax.

I'm assuming that this (and the changes to the various dumpfiles in
patches 8b-8d) count as "obvious".

gcc/ChangeLog:
* read-rtl-function.c (lookup_reg_by_dump_name): Rework to expect
regno wrapped in '<' and '>' rather than with a '%' prefix.
(selftest::test_parsing_regnos): Update for above change.
---
 gcc/read-rtl-function.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/read-rtl-function.c b/gcc/read-rtl-function.c
index c3f5c64..24f7deb 100644
--- a/gcc/read-rtl-function.c
+++ b/gcc/read-rtl-function.c
@@ -352,10 +352,10 @@ lookup_reg_by_dump_name (const char *name)
 return VIRTUAL_PREFERRED_STACK_BOUNDARY_REGNUM;
   /* TODO: handle "virtual-reg-%d".  */
 
-  /* In compact mode, pseudos are printed with a '%' sigil following
- by the regno, offset by (LAST_VIRTUAL_REGISTER + 1), so that the
- first non-virtual pseudo is dumped as "%0".  */
-  if (name[0] == '%')
+  /* In compact mode, pseudos are printed with '< and '>' wrapping the regno,
+ offseting it by (LAST_VIRTUAL_REGISTER + 1), so that the
+ first non-virtual pseudo is dumped as "<0>".  */
+  if (name[0] == '<' && name[strlen (name) - 1] == '>')
 {
   int dump_num = atoi (name + 1);
   return dump_num + LAST_VIRTUAL_REGISTER + 1;
@@ -1681,8 +1681,8 @@ test_parsing_regnos ()
 lookup_reg_by_dump_name ("virtual-preferred-stack-boundary"));
 
   /* Verify lookup of non-virtual pseudos.  */
-  ASSERT_EQ (LAST_VIRTUAL_REGISTER + 1, lookup_reg_by_dump_name ("%0"));
-  ASSERT_EQ (LAST_VIRTUAL_REGISTER + 2, lookup_reg_by_dump_name ("%1"));
+  ASSERT_EQ (LAST_VIRTUAL_REGISTER + 1, lookup_reg_by_dump_name ("<0>"));
+  ASSERT_EQ (LAST_VIRTUAL_REGISTER + 2, lookup_reg_by_dump_name ("<1>"));
 }
 
 /* Verify that edge E is as expected, with the src and dest basic blocks
-- 
1.8.5.3

[Bug fortran/78757] [7 Regression] ICE with function returning a pointer to a character

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78757

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek  ---
Fixed.

Re: [PATCH] Emit DECL_EXPR so that type of what pstr.N points to is gimplified (PR fortran/78757)

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 09:31:37PM +0200, Janne Blomqvist wrote:
> On Wed, Dec 14, 2016 at 11:55 PM, Jakub Jelinek  wrote:
> > Hi!
> >
> > The gimplifier (because of Ada :( ) doesn't recurse to POINTER_TYPE's
> > type when gimplifying types, so we need a DECL_EXPR to gimplify such
> > types if they are VLAs.  The following patch is an attempt to do that.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Ok, but could you name the testcase something more descriptive, say,
> char_result_16.f90?

Thanks, I've also changed the 70_8 to 30_8 in the testcase, so that it is
clearly valid.  It still ICEs without the patch and works with the patch.

So here is what I've committed:

2016-12-16  Jakub Jelinek  

PR fortran/78757
* trans-expr.c (gfc_conv_procedure_call): Emit DECL_EXPR for the
type pstr var points to.

* gfortran.dg/char_result_16.f90: New test.

--- gcc/fortran/trans-expr.c.jj 2016-12-09 20:32:39.0 +0100
+++ gcc/fortran/trans-expr.c2016-12-14 15:22:50.142968565 +0100
@@ -6009,6 +6009,19 @@ gfc_conv_procedure_call (gfc_se * se, gf
{
  var = gfc_create_var (type, "pstr");
 
+ /* Emit a DECL_EXPR for the VLA type.  */
+ tmp = TREE_TYPE (type);
+ if (TYPE_SIZE (tmp)
+ && TREE_CODE (TYPE_SIZE (tmp)) != INTEGER_CST)
+   {
+ tmp = build_decl (input_location, TYPE_DECL, NULL_TREE, tmp);
+ DECL_ARTIFICIAL (tmp) = 1;
+ DECL_IGNORED_P (tmp) = 1;
+ tmp = fold_build1_loc (input_location, DECL_EXPR,
+TREE_TYPE (tmp), tmp);
+ gfc_add_expr_to_block (>pre, tmp);
+   }
+
  if ((!comp && sym->attr.allocatable)
  || (comp && comp->attr.allocatable))
{
--- gcc/testsuite/gfortran.dg/char_result_16.f90.jj 2016-12-14 
15:28:09.707932278 +0100
+++ gcc/testsuite/gfortran.dg/char_result_16.f902016-12-14 
15:27:54.0 +0100
@@ -0,0 +1,16 @@
+! PR fortran/78757
+! { dg-do compile }
+! { dg-options "-O1" }
+
+program pr78757
+  implicit none
+  character (len = 30), target :: x
+  character (len = 30), pointer :: s
+  s => foo (30_8)
+contains
+  function foo (i)
+integer (8) :: i
+character (len = i), pointer :: foo
+foo => x
+  end function foo
+end program pr78757


Jakub

[Bug fortran/78757] [7 Regression] ICE with function returning a pointer to a character

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78757

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 16 19:41:13 2016
New Revision: 243761

URL: https://gcc.gnu.org/viewcvs?rev=243761=gcc=rev
Log:
PR fortran/78757
* trans-expr.c (gfc_conv_procedure_call): Emit DECL_EXPR for the
type pstr var points to.

* gfortran.dg/char_result_16.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char_result_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] Emit DECL_EXPR so that type of what pstr.N points to is gimplified (PR fortran/78757)

[Janne Blomqvist]

On Wed, Dec 14, 2016 at 11:55 PM, Jakub Jelinek  wrote:
> Hi!
>
> The gimplifier (because of Ada :( ) doesn't recurse to POINTER_TYPE's
> type when gimplifying types, so we need a DECL_EXPR to gimplify such
> types if they are VLAs.  The following patch is an attempt to do that.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok, but could you name the testcase something more descriptive, say,
char_result_16.f90?

>
> 2016-12-14  Jakub Jelinek  
>
> PR fortran/78757
> * trans-expr.c (gfc_conv_procedure_call): Emit DECL_EXPR for the
> type pstr var points to.
>
> * gfortran.dg/pr78757.f90: New test.
>
> --- gcc/fortran/trans-expr.c.jj 2016-12-09 20:32:39.0 +0100
> +++ gcc/fortran/trans-expr.c2016-12-14 15:22:50.142968565 +0100
> @@ -6009,6 +6009,19 @@ gfc_conv_procedure_call (gfc_se * se, gf
> {
>   var = gfc_create_var (type, "pstr");
>
> + /* Emit a DECL_EXPR for the VLA type.  */
> + tmp = TREE_TYPE (type);
> + if (TYPE_SIZE (tmp)
> + && TREE_CODE (TYPE_SIZE (tmp)) != INTEGER_CST)
> +   {
> + tmp = build_decl (input_location, TYPE_DECL, NULL_TREE, 
> tmp);
> + DECL_ARTIFICIAL (tmp) = 1;
> + DECL_IGNORED_P (tmp) = 1;
> + tmp = fold_build1_loc (input_location, DECL_EXPR,
> +TREE_TYPE (tmp), tmp);
> + gfc_add_expr_to_block (>pre, tmp);
> +   }
> +
>   if ((!comp && sym->attr.allocatable)
>   || (comp && comp->attr.allocatable))
> {
> --- gcc/testsuite/gfortran.dg/pr78757.f90.jj2016-12-14 15:28:09.707932278 
> +0100
> +++ gcc/testsuite/gfortran.dg/pr78757.f90   2016-12-14 15:27:54.0 
> +0100
> @@ -0,0 +1,16 @@
> +! PR fortran/78757
> +! { dg-do compile }
> +! { dg-options "-O1" }
> +
> +program pr78757
> +  implicit none
> +  character (len = 30), target :: x
> +  character (len = 30), pointer :: s
> +  s => foo (70_8)
> +contains
> +  function foo (i)
> +integer (8) :: i
> +character (len = i), pointer :: foo
> +foo => x
> +  end function foo
> +end program pr78757
>
> Jakub



-- 
Janne Blomqvist

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Jeff Law]

On 12/16/2016 06:57 AM, Richard Biener wrote:

On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law  wrote:

+  /* REF is a memory write.  Go ahead and get its base, size, extent
+ information and encode the bytes written into LIVE_BYTES.  We can
+ handle any case where we have a known base and maximum size.
+
+ However, experimentation has shown that bit level tracking is not
+ useful in practice, so we only track at the byte level.
+
+ Furthermore, experimentation has shown that 99% of the cases
+ that require byte tracking are 64 bytes or less.  */
+  if (valid_ao_ref_for_dse (ref)
+  && (ref->max_size / BITS_PER_UNIT
+ <= PARAM_VALUE (PARAM_DSE_MAX_OBJECT_SIZE)))
+{
+  live_bytes = BITMAP_ALLOC (NULL);
+  orig_live_bytes = BITMAP_ALLOC (NULL);
+  bitmap_set_range (live_bytes,
+   ref->offset / BITS_PER_UNIT,
+   ref->max_size / BITS_PER_UNIT);
+  bitmap_copy (orig_live_bytes, live_bytes);


So I'd use a once-per-pass allocated sbitmap here.  I don't see why you need
the orig_live_bytes bitmap though (just keep that implicitely by the known
range?)
So if we use a once-per-pass allocated bitmap, that actually facilitates 
returning a tri-state from dse_possible_dead_store_p and moving the 
trimming into dse_optimize_stmt.


ORIG_LIVE_BYTES was more convenience than anything -- we want it so that 
we can compute the dead bytes for trimming.  But we can certainly 
compute it on-demand at that time.


Jeff

Re: using C++ STL containers in GCC/gfortran source code

[Pedro Alves]

On 12/16/2016 06:56 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote:
>> GDB has a string_printf function that prints into a std::string, for
>> example.  Like:
>>
>>   std::string hello = string_printf ("%s", "hello world");
>>
>> That's a function that many C++ projects reinvent.
> 
> If you then want to work with it as std::string object, sure, it makes
> sense.  But if all you want is to pass the string to %s of another
> formatting function and free it, then going through std::string
> doesn't add many benefits over just xasprintf + free.

It has all the usual advantages of RAII.  
It completely eliminates the "forgot to call free in this
exit path" bug by design.

And then there's exception safety, in case something throws
beforeyou reach the "+ free".

(I know GCC doesn't use exceptions; GDB does.  But do note
https://gcc.gnu.org/codingrationale.html says:

 We would like the compiler to be exception safe, to permit
 reconsideration of the exception convention. This change
 would require a significant change in style,
 adopting "resource acquisition is initialization" (RAII). We would be 
 using shared_ptr (from TR1's ) or unique_ptr (from C++11).
)

We've started using RAII objects in GDB in the past couple
months, including C++11 unique_ptr, and that has already
simplified the codebase a good deal, and fixed many leaks
and bugs.

Thanks,
Pedro Alves

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 07:00:06PM +, Joseph Myers wrote:
> On Fri, 16 Dec 2016, Martin Sebor wrote:
> 
> > I don't claim it can't be improved but it seems pretty good as
> > it is already.  Among the 6 instances it's found in GCC three
> > look like real bugs.
> 
> FWIW it's found at least one real bug in glibc 
>  - that's a case 
> where strlen is called on a pointer that can never be non-null if the 
> strlen call is reached.  (I don't know if there are other cases in glibc, 
> whether genuine bugs or false positives, that would appear later in the 
> build once that bug is fixed.)

Thanks.  Reduced to something like:
int
foo (const char *name)
{
  if (name)
return 6;
  return __builtin_strlen (name);
}
This is warned about both with Martin's late warning and my after ccp2
warning version.  We should include it in gcc testsuite.

Jakub

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Joseph Myers]

On Fri, 16 Dec 2016, Martin Sebor wrote:

> I don't claim it can't be improved but it seems pretty good as
> it is already.  Among the 6 instances it's found in GCC three
> look like real bugs.

FWIW it's found at least one real bug in glibc 
 - that's a case 
where strlen is called on a pointer that can never be non-null if the 
strlen call is reached.  (I don't know if there are other cases in glibc, 
whether genuine bugs or false positives, that would appear later in the 
build once that bug is fixed.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Jeff Law]

On 12/16/2016 06:57 AM, Richard Biener wrote:

On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law  wrote:

+   {
+ /* STMT might be partially dead and we may be able to reduce
+how many memory locations it stores into.  */
+ if (live_bytes
+ && !bitmap_equal_p (live_bytes, orig_live_bytes)
+ && !gimple_clobber_p (stmt))
+   trim_partially_dead_store (orig_live_bytes, live_bytes, stmt);


The actual transform in dse_possible_dead_store_p looks a bit misplaced.
I see it's somehow convenient but then maybe returning a enum from this
function might be cleaner.  Well, I'm not too torn about this, so maybe
just rename the function a bit (no good suggestion either).
So the problem with returning a tri-state is that we'd also need to 
return the bitmaps or trimming data so that our caller would know how to 
trim in the partially dead case.  Certainly possible, though marginally 
more awkward from an implementation standpoint.  Renaming seems 
appropriate since dse_possible_dead_store_p does more than just detect a 
dead store with these changes.


Jeff

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Joseph Myers]

On Fri, 16 Dec 2016, Jakub Jelinek wrote:

> On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote:
> > On Thu, 15 Dec 2016, Jeff Law wrote:
> > 
> > > This version attacks the problem by improving DSE to track stores to 
> > > memory at
> > > a byte level.  That allows us to determine if a series of stores 
> > > completely
> > > covers an earlier store (thus making the earlier store dead).
> > 
> > Question: suppose you have an assignment for a struct with padding, then 
> > stores for all the elements.  Does it detect that the original assignment 
> > is dead (because there is no need to copy padding on struct assignment)?
> 
> We fold memcpy into struct assignment early, does the same apply also to
> memcpy?  Or shall we fold memcpy into struct assignment only when there is
> no padding (or find different IL representation of that)?

There is at least an arguable case that memset needs to set padding to 0 
(unlike initializers), and memcpy needs to copy it (unlike struct 
assignment).  Atomic compare-exchange definitely needs to work on the 
whole representation including padding.

However, when you store in a member of a structure (or union), that 
results in all the padding becoming undefined.  So in the cases of memcpy 
/ memset where this optimization is interesting (element stores follow the 
memcpy / memset), you can still optimize.

(Note the desire for an option to avoid such padding-related 
optimizations, by treating padding for optimization purposes as if there 
were dummy fields there that can all be cleared by a {} initializer or 
memset: PR 77992.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Do we really need a CPP manual?

[Jim Wilson]

On 12/16/2016 10:06 AM, Jeff Law wrote:

That's likely the manual RMS kept asking folks (semi-privately) to
review.  My response was consistently that such review should happen
publicly, which RMS opposed for reasons I don't recall.


I reviewed it, on the grounds that a happy rms is good for the gcc 
project, and because I haven't been doing much else useful.  It was a 
lot of work, about 10 hours a week for 2 months.  The document I 
reviewed has significant differences from the one on the web site, but 
has a lot of structural similarities.  I think there is a major rewrite 
still in progress.  I pointed out all of the obvious stuff, features 
dropped long ago, references to out-of-date standards, missing ISO C 
2011 features, etc.


Jim

Re: using C++ STL containers in GCC/gfortran source code

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote:
> GDB has a string_printf function that prints into a std::string, for
> example.  Like:
> 
>   std::string hello = string_printf ("%s", "hello world");
> 
> That's a function that many C++ projects reinvent.

If you then want to work with it as std::string object, sure, it makes
sense.  But if all you want is to pass the string to %s of another
formatting function and free it, then going through std::string
doesn't add many benefits over just xasprintf + free.

Jakub

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Jeff Law]

On 12/16/2016 11:43 AM, Jakub Jelinek wrote:

On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote:

On Thu, 15 Dec 2016, Jeff Law wrote:


This version attacks the problem by improving DSE to track stores to memory at
a byte level.  That allows us to determine if a series of stores completely
covers an earlier store (thus making the earlier store dead).


Question: suppose you have an assignment for a struct with padding, then
stores for all the elements.  Does it detect that the original assignment
is dead (because there is no need to copy padding on struct assignment)?


We fold memcpy into struct assignment early, does the same apply also to
memcpy?  Or shall we fold memcpy into struct assignment only when there is
no padding (or find different IL representation of that)?

So a memcpy would presumably cover the entire object, padding included.

Subsequent component stores would not cover the padding.  So we'd trim 
the head/tail of the memcpy.



A memcpy folded to a structure assignment almost certainly covers the 
whole assignment when represented in an ao_ref.  So it'd be no different 
-- except that I haven't written code to trim structure assignments 
(unless they're represented by a CONSTRUCTOR assignment).  Regardless I 
would not suggest changing if/how/when we fold memcpy into a structure 
assignment.


Jeff

Re: using C++ STL containers in GCC/gfortran source code

[Pedro Alves]

On 12/16/2016 06:04 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote:
>> To get to more specific questions ...
>>
>>> Basically the only STL construct used in the Fortran FE right now
>>> seems to be std::swap, and a single instance of std::map in
>>> trans-common.c.
>>
>> I see that fortran/trans-common.c has:
>>
>> #define INCLUDE_MAP
>>
>> and apparently there is also a INCLUDE_STRING macro. I guess if I want
>> to use std::string I don't #include , but #define
>> INCLUDE_STRING, right? Why are those macros needed, exactly?
> 
> They are needed because system.h poisons lots of things, including malloc
> etc.  So including system headers after system.h is problematic.

IMO, GCC's poison (or a variant) should ignore system headers.  There's
nothing one can do with those.  It's _uses_ in one's code that generally
one wants to prevent with the poisoning.

> 
> That said, using std::string for what you talk in the PR would make it
> impossible to translate it, if you build a sentence as:
>   ss << "Argument " << something () << " and '" << something_else () << "'";
> then our framework can't deal with that, translating portions of a sentence
> is not going to be useful for many languages.
> Using *printf or similar formatting strings allows the translator to see
> the whole sentence with arguments, and e.g. when needed can swap
> some arguments using %4$s syntax etc.

The problem is not std::string here, but the stream operators.
And I agree.

GDB has a string_printf function that prints into a std::string, for
example.  Like:

  std::string hello = string_printf ("%s", "hello world");

That's a function that many C++ projects reinvent.

Re: [PATCH] Remove unused libgfortran functions

[Steve Kargl]

On Fri, Dec 16, 2016 at 07:46:01PM +0200, Janne Blomqvist wrote:
> On Fri, Dec 16, 2016 at 4:02 PM, FX  wrote:
> > A few questions:
> >
> >   1. Regarding gfortran.map, shouldn’t we just flatten out all the symbols 
> > from GFORTRAN_1.0 to GFORTRAN_1.7 into a single new GFORTRAN_2.0 group 
> > (while removing the ones we are getting rid of)?
> 
> Yes, I agree (in general, though I was thinking of making the new one
> "GFORTRAN_7" to match the release series). There's also other things,
> like e.g. ISO_C_BINDING helper functions living under the
> __iso_c_binding namespace, instead of under _gfortran like everything
> else. And while we're at it, should we place everything under
> "__gfortran" or "_GFortran", that is, with two underscores or one
> underscore followed by a capital letter which in the C world is
> reserved for the implementation? Though it's not clear to me whether
> libgfortran can claim to be part of "the implementation" vs. being
> generic user code.

That's an interessting question.  All of the intrinsic subprogams
in Section 13 of the standard are required by the implementation.
This suggests that _GFortran should be used.  The Fortran standard
does allow a processor to supply additional intrinsic subprograms
beyond those in Section 13 (e.g., all of the g77 compatibility
routines).  I think we should simply use the same prefix.  I'll
leave the choice to whoever does the work. :-)

-- 
Steve

[Bug debug/72828] ICE in clone_tree_partial when compiling with -fdebug-types-section

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72828

--- Comment #7 from Nathan Sidwell  ---
With 78835 patched using Jakub's diff in comment 1, this no longer ices.

Re: using C++ STL containers in GCC/gfortran source code

[Pedro Alves]

On 12/16/2016 06:31 PM, Janus Weil wrote:
> 2016-12-16 18:53 GMT+01:00 Pedro Alves :
>> On 12/16/2016 05:33 PM, Janus Weil wrote:

>>> And in particular: How do the current uses of
>>> std::string in GCC deal with this problem? (Do they?)
>>
>> Doesn't look like they do.
> 
> Huh, that's a problem then, isn't it?

Right.  The easiest way to trigger it I think is if something
computes some size incorrectly, and calls for example string::reserve(-1)
or string::resize(-1) by mistake (likewise for std::vector, etc.).
malloc will fail, new will throw bad_alloc, and GCC will abort and
maybe generate a core dump, instead of gracefully printing
something like:

   cc1: out of memory allocating  bytes ...

and existing with error status.

Thanks,
Pedro Alves

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Jeff Law]

On 12/16/2016 11:35 AM, Joseph Myers wrote:

On Thu, 15 Dec 2016, Jeff Law wrote:


This version attacks the problem by improving DSE to track stores to memory at
a byte level.  That allows us to determine if a series of stores completely
covers an earlier store (thus making the earlier store dead).


Question: suppose you have an assignment for a struct with padding, then
stores for all the elements.  Does it detect that the original assignment
is dead (because there is no need to copy padding on struct assignment)?
It would not detect the original assignment as dead in that case as it 
does not know anything special about the padding bytes.


So we'd likely end up just trimming the original assignment, 
particularly if it was done via a CONSTRUCTOR assignment or memset.


This situation could be addressed by handling the padding bytes 
specially -- ie, just clear them from LIVE when LIVE is initialized. 
It'd likely "just work" then.


Seems like it might be a reasonable follow-up as it'd hopefully make 
more of the original assignments fully dead rather than just trimmable.


jeff

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 06:35:58PM +, Joseph Myers wrote:
> On Thu, 15 Dec 2016, Jeff Law wrote:
> 
> > This version attacks the problem by improving DSE to track stores to memory 
> > at
> > a byte level.  That allows us to determine if a series of stores completely
> > covers an earlier store (thus making the earlier store dead).
> 
> Question: suppose you have an assignment for a struct with padding, then 
> stores for all the elements.  Does it detect that the original assignment 
> is dead (because there is no need to copy padding on struct assignment)?

We fold memcpy into struct assignment early, does the same apply also to
memcpy?  Or shall we fold memcpy into struct assignment only when there is
no padding (or find different IL representation of that)?

Jakub

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 07:29:13PM +0100, Markus Trippelsdorf wrote:
> So, to be fair a gave Jakub's patch a try and it has exactly the same
> issues for the Linux kernel: sometimes the warning only triggers with
> -O3, e.g.:
> 
>  % cat sm_ftl.i
> int a;
> void mtd_read_oob(int);
> void sm_read_sector(int *buffer) {
>   __builtin_memset(buffer, 0, 1);
>   mtd_read_oob(a);
> }
> void sm_get_zone() { sm_read_sector(0); }

In this case I think the warning is right, if you ever call sm_get_zone,
it will always invoke UB.

>  % gcc -c -Wnonnull -O2 sm_ftl.i
>  % gcc -c -Wnonnull -O3 sm_ftl.i
> sm_ftl.i: In function ‘sm_get_zone’:
> sm_ftl.i:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
>__builtin_memset(buffer, 0, 1);
>^~
> sm_ftl.i:4:3: note: in a call to built-in function ‘__builtin_memset’
> 
> Also, Jakub's patch doesn't catch the following case:
> 
> (tools/perf/util/trace-event-info.c from Linux)
> //...
> dir = opendir(path);
> if (!dir) {
> err = -errno;
> pr_debug("can't read directory '%s'", path);
> goto out;
> }
> //... other stuff
> out:
> closedir(dir);
> 
> Whereas Martin's does.

This is where you rely on jump threading to duplicate closedir,
otherwise you don't warn.  If you don't jump thread it (say there are
a few more statements after closedir that make it not worth it), then you
don't warn even late.  If the warning in calls.c is guarded with
-Wmaybe-nonnull instead of -Wnonnull, not included in -Wall, I have no
objections.  Then users can select the amount of warnings and false
positives.  Or -Wnonnull can have 3 levels, one warn in the FE only,
then after inlining in the second level and late in the 3rd level.

Jakub

Re: [RFA] [PR tree-optimization/33562] [PATCH 1/4] Byte tracking in DSE

[Joseph Myers]

On Thu, 15 Dec 2016, Jeff Law wrote:

> This version attacks the problem by improving DSE to track stores to memory at
> a byte level.  That allows us to determine if a series of stores completely
> covers an earlier store (thus making the earlier store dead).

Question: suppose you have an assignment for a struct with padding, then 
stores for all the elements.  Does it detect that the original assignment 
is dead (because there is no need to copy padding on struct assignment)?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] nvptx: do not assume that crtl->is_leaf is unset

[Jeff Law]

On 12/16/2016 09:48 AM, Alexander Monakov wrote:

Hi,

Until a recent change, crtl->is_leaf was initialized only during IRA startup.
On NVPTX, register allocation is not done, so the backend asserts that this
field is unset, and recomputes it unconditionally.

Now this field can be optionally set via ira_setup_eliminable_regset for
register-pressure-sensitive optimizations, so the assumption in the backend no
longer holds.  Remove the assert, but avoid recomputing the field if it is
already set, indicating that the function is known to be leaf.

OK to apply?

Thanks.
Alexander

PR target/78831
* config/nvptx/nvptx.c (init_softstack_frame): Remove assert.  Compute
crtl->is_leaf only if unset.  Adjust comment.

OK.
jeff

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

2016-12-16 18:53 GMT+01:00 Pedro Alves :
> On 12/16/2016 05:33 PM, Janus Weil wrote:
>
>> "You would need to make sure it uses a xmalloc based allocator first
>> or at least calls xmalloc_failed upon allocation failure, otherwise it
>> will be a serious regression."
>>
>> I'm really not an expert on GCC's memory management principles and how
>> it uses xmalloc over malloc. I'd love to hear further comments on the
>> above sentence (e.g. whether that is really necessary, and if yes, how
>> to accomplish it).
>
> I gave a suggestion in the PR.
>
> Basically, you can replace the global operator new to call xmalloc
> instead of malloc.  See the GDB url in the PR for an example.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822#c19

Thanks for the comment!


>> And in particular: How do the current uses of
>> std::string in GCC deal with this problem? (Do they?)
>
> Doesn't look like they do.

Huh, that's a problem then, isn't it?

Cheers,
Janus

[Bug rtl-optimization/65618] [5/6/7 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Component|target  |rtl-optimization

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Markus Trippelsdorf]

On 2016.12.16 at 11:07 -0700, Martin Sebor wrote:
> On 12/16/2016 10:27 AM, Jakub Jelinek wrote:
> > On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:
> > > > No.  The first call to sm_read_sector just doesn't exit.  So it is 
> > > > warning
> > > > about dead code.
> > >
> > > If the code is dead then GCC should eliminate it.  With it eliminated
> >
> > There is (especially with jump threading, but not limited to that, other
> > optimizations may result in that too), code that even very smart optimizing
> > compiler isn't able to prove that is dead.
> >
> > > the warning would be gone.  The warning isn't smart and it doesn't
> > > try to be.  It only works with what GCC gives it.  In this case the
> > > dump shows that GCC thinks the code is reachable.  If it isn't that
> > > would seem to highlight a missed optimization opportunity, not a need
> > > to make the warning smarter than the optimizer.
> >
> > No, it highlights that the warning is done in a wrong place where it suffers
> > from too many false positives.
>
> Asserting a claim without providing any data or evidence doesn't make
> it true.  We have seen fewer than 10 instances of it in just one out
> of four sizable projects.  At least three of these instances are
> debatable (as evidenced by the ongoing debate).  That can hardly be
> interpreted as "too many false positives."

So, to be fair a gave Jakub's patch a try and it has exactly the same
issues for the Linux kernel: sometimes the warning only triggers with
-O3, e.g.:

 % cat sm_ftl.i
int a;
void mtd_read_oob(int);
void sm_read_sector(int *buffer) {
  __builtin_memset(buffer, 0, 1);
  mtd_read_oob(a);
}
void sm_get_zone() { sm_read_sector(0); }

 % gcc -c -Wnonnull -O2 sm_ftl.i
 % gcc -c -Wnonnull -O3 sm_ftl.i
sm_ftl.i: In function ‘sm_get_zone’:
sm_ftl.i:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_memset(buffer, 0, 1);
   ^~
sm_ftl.i:4:3: note: in a call to built-in function ‘__builtin_memset’

Also, Jakub's patch doesn't catch the following case:

(tools/perf/util/trace-event-info.c from Linux)
//...
dir = opendir(path);
if (!dir) {
err = -errno;
pr_debug("can't read directory '%s'", path);
goto out;
}
//... other stuff
out:
closedir(dir);

Whereas Martin's does.

--
Markus

[Bug ipa/77905] [5/6 Regression] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77905

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE at   |[5/6 Regression] ICE at -Os
   |-Os and above in both   |and above in both 32-bit
   |32-bit and 64-bit modes on  |and 64-bit modes on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: in  |compiler error: in
   |ipa_comdats, at |ipa_comdats, at
   |ipa-comdats.c:352)  |ipa-comdats.c:352)

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/77844] [5 Regression] Compilation of simple C++ example exhaust memory

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77844

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/7 Regression]|[5 Regression] Compilation
   |Compilation of simple C++   |of simple C++ example
   |example exhaust memory  |exhaust memory

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.

New French PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/gcc/fr.po

(This file, 'gcc-6.2.0.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] Add assertion to _Rb_tree::erase to check for end iterators

[Jonathan Wakely]

This adds assertions to catch assoc.erase(assoc.end()) when
_GLIBCXX_ASSERTIONS is defined. Without the assertion it usually leads
to a double free, which leads to termination for some mallocs anyway.

Because the erase(first, last) form called erase(first++) in a loop
I've changed that to bypass it and go straight to _M_erase_aux(first++),
so it doesn't do the assertion on every iteration of the loop. That
means the assertion won't fail in a case like this:

   std::set s1, s2;
   s1.erase(s1.begin(), s2.end());

If we checked the assertion then when we reached the end of s1 we'd
abort, rather than try to keep incrementing the first iterator until
we reach the end of the other container (which will never happen). I
think this mistake is much less common, and checking the assertion on
every iteration isn't worth it. (The full-fat Debug Mode still catches
that mistake).

The erase(const Key&) form also called erase(iter) in a loop, and in
that case we know that iter != end() for all calls, so the assertion
is definitely not valuable.

* include/bits/stl_tree.h (_Rb_tree::_M_erase_aux(const_iterator)):
Add assertion for undefined argument.
(_Rb_tree::_M_erase_aux(const_iterator, const_iterator)): Call
_M_erase_aux directly instead of through erase.
(_Rb_tree::_M_erase_aux(const Key&)): Likewise.
* testsuite/23_containers/map/modifiers/erase/end_neg.cc: New test.

There's also a second patch to re-use the Doxygen comments for
erase(const_iterator) for the erase(iterator) overloads.

Tested x86_64-linux, committed to trunk.

commit 0179abf0b86f5b833a653213941f07448be2d5ab
Author: Jonathan Wakely 
Date:   Fri Dec 16 14:21:53 2016 +

Add assertion to _Rb_tree::erase to check for end iterators

* include/bits/stl_tree.h (_Rb_tree::_M_erase_aux(const_iterator)):
Add assertion for undefined argument.
(_Rb_tree::_M_erase_aux(const_iterator, const_iterator)): Call
_M_erase_aux directly instead of through erase.
(_Rb_tree::_M_erase_aux(const Key&)): Likewise.
* testsuite/23_containers/map/modifiers/erase/end_neg.cc: New test.

diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index 925066c..735fada 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -1104,6 +1104,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   iterator
   erase(const_iterator __position)
   {
+   __glibcxx_assert(__position != end());
const_iterator __result = __position;
++__result;
_M_erase_aux(__position);
@@ -1115,6 +1116,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   iterator
   erase(iterator __position)
   {
+   __glibcxx_assert(__position != end());
iterator __result = __position;
++__result;
_M_erase_aux(__position);
@@ -1123,11 +1125,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #else
   void
   erase(iterator __position)
-  { _M_erase_aux(__position); }
+  {
+   __glibcxx_assert(__position != end());
+   _M_erase_aux(__position);
+  }
 
   void
   erase(const_iterator __position)
-  { _M_erase_aux(__position); }
+  {
+   __glibcxx_assert(__position != end());
+   _M_erase_aux(__position);
+  }
 #endif
   size_type
   erase(const key_type& __x);
@@ -2477,7 +2485,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
clear();
   else
while (__first != __last)
- erase(__first++);
+ _M_erase_aux(__first++);
 }
 
   template __p = equal_range(__x);
   const size_type __old_size = size();
-  erase(__p.first, __p.second);
+  _M_erase_aux(__p.first, __p.second);
   return __old_size - size();
 }
 
diff --git 
a/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/end_neg.cc 
b/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/end_neg.cc
new file mode 100644
index 000..f01a99b
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/end_neg.cc
@@ -0,0 +1,35 @@
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-D_GLIBCXX_ASSERTIONS" }
+// { dg-do run { xfail *-*-* } }
+
+#include 
+
+void
+test01()
+{
+  

Re: [PATCH] PR 78534 Change character length from int to size_t

[Dominique d'Humières]

> Le 16 déc. 2016 à 19:06, Janne Blomqvist  a écrit :
> 
> On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières
>  wrote:
>> Hi Janne,
>> 
>> I have applied your two patches and found that I had to skip the patches for 
>> resolve.c and match.c due to the errors
>> 
>> ../../p_work/gcc/fortran/resolve.c: In function 'void 
>> resolve_select_type(gfc_code*, gfc_namespace*)':
>> ../../p_work/gcc/fortran/resolve.c:8731:58: error: format '%lld' expects 
>> argument of type 'long long int', but argument 4 has type 'long int' 
>> [-Werror=format=]
>>  gfc_basic_typename (c->ts.type), charlen, c->ts.kind);
>> 
>> and
>> 
>> ../../p_work/gcc/fortran/match.c: In function 'gfc_symtree* 
>> select_intrinsic_set_tmp(gfc_typespec*)':
>> ../../p_work/gcc/fortran/match.c:5786:55: error: format '%lld' expects 
>> argument of type 'long long int', but argument 4 has type 'long int' 
>> [-Werror=format=]
>>   gfc_basic_typename (ts->type), charlen, ts->kind);
>> 
> 
> Oh, blast. Of course you're right, from the second patch, the part
> that touched resolve.c and match.c are incorrect.
> 
>> while the patch for dump-parse-tree.c was needed.
>> 
>> With the patches applied I see several failures in the test suite compiled 
>> with ‘-m64 -flto’, but not with ‘-m32 -flto’ of the kind
> 
> Ok, thanks for the hint. I haven't tested with -flto.  Do you just run
> it with something like
> 
> CFLAGS="-flto" make -j $NCPUS check-fortran
> 
> or how do you do it?

Due to recurrent problems with -flto, I have the following change in my working 
tree

--- ../_clean/gcc/testsuite/lib/gfortran-dg.exp 2016-02-12 20:21:04.0 
+0100
+++ gcc/testsuite/lib/gfortran-dg.exp   2016-02-13 10:03:11.0 +0100
@@ -140,8 +140,16 @@ proc gfortran-dg-runtest { testcases fla
# we cycle through the option list, otherwise we don't
if [expr [search_for $test "dg-do run"]] {
set option_list $torture_with_loops
+   if [check_effective_target_lto] {
+   lappend option_list { -g -flto }
+   # lappend option_list { -g -O3 -fwhole-program -flto }
+   }
} else {
set option_list [list { -O } ]
+   # if [check_effective_target_lto] {
+   # lappend option_list { -g -flto }
+   # lappend option_list { -g -O3 -fwhole-program -flto }
+   # }
}
 
set nshort [file tail [file dirname $test]]/[file tail $test]

i.e., I add the options ‘-g -flto’ to the list of options used by the gfortran 
test suite.

> 
> I don't have lldb, but I guess I can see roughly the same with gdb..

For what I do, it is close to gdb (I did not succeed to authorize it on recent 
darwin).

Dominique

>> The affected tests are
>> 
>> array_constructor_17.f90
>> auto_char_len_3.f90
>> char_length_14.f90
>> char_length_5.f90
>> char_result_*.f90
>> charlen_03.f90
>> deferred_type_param_4.f90
>> dummy_procedure_3.f90
>> mapping_[12].f90
>> module_read_[12].f90
>> parens_5.f90
>> pr57910.f90
>> proc_ptr_comp_16.f90
>> result_in_spec_2.f90
>> spec_expr_7.f90
>> string_length_1.f90
>> transfer_intrinsic_3.f90
>> widechar_6.f90
>> zero_length_1.f90
>> 
>> Note that I did not run lldb on all of them, thus I cannot guarantee that 
>> all fail along the same pattern.
>> 
>> Cheers,
>> 
>> Dominique
>> 
> 
> 
> 
> -- 
> Janne Blomqvist

Re: using C++ STL containers in GCC/gfortran source code

[N.M. Maclaren]

On Dec 16 2016, Janus Weil wrote:


thanks for this lengthy comment, but that's really not the kind of
discussion I wanna get into here. (And I don't actually agree to all
of your points, but that doesn't matter.)


Sorry - I misunderstood.

Regards,
Nick Maclaren.

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 11:07:29AM -0700, Martin Sebor wrote:
> If your implementation diagnoses the common cases exercised by the
> tests I wrote I have no objection to it (not that objecting would
> do me any good).

Your tests all pass with the patch I've posted, we can surely add further
ones if needed.
Anyway, I think I've posted what I wanted to say on the topic, so let's
wait for others to decide what we want to do, somebody has to ack either of
the patches (or some other, or request reversion).

Jakub

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835

--- Comment #3 from Nathan Sidwell  ---
started failing with:
r240578 | rguenth | 2016-09-28 07:30:19 -0700 (Wed, 28 Sep 2016) | 17 lines

2016-09-28  Richard Biener  

* dwarf2out.c (struct die_struct): Add removed flag.
(lookup_type_die): If the DIE is marked as removed, clear
TYPE_SYMTAB_DIE and return NULL.
(lookup_decl_die): If the DIE is marked as removed, remove it
from the hash and return NULL.
(mark_removed): New helper.
(prune_unused_types_prune): Call it for removed DIEs.
(gen_subprogram_die): Move the premark_used_types call to after
DIEs for the functions scopes are generated.
(process_scope_var): Do not re-create pruned types or type decls.
Make sure to also re-parent type decls.
(dwarf2out_finish): Move unused type pruning and debug_types
handling ...
(dwarf2out_early_finish): ... here.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-16
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Note this regressed with r240578.

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

[Martin Sebor]

On 12/16/2016 10:27 AM, Jakub Jelinek wrote:

On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote:

No.  The first call to sm_read_sector just doesn't exit.  So it is warning
about dead code.


If the code is dead then GCC should eliminate it.  With it eliminated


There is (especially with jump threading, but not limited to that, other
optimizations may result in that too), code that even very smart optimizing
compiler isn't able to prove that is dead.


the warning would be gone.  The warning isn't smart and it doesn't
try to be.  It only works with what GCC gives it.  In this case the
dump shows that GCC thinks the code is reachable.  If it isn't that
would seem to highlight a missed optimization opportunity, not a need
to make the warning smarter than the optimizer.


No, it highlights that the warning is done in a wrong place where it suffers
from too many false positives.


Asserting a claim without providing any data or evidence doesn't make
it true.  We have seen fewer than 10 instances of it in just one out
of four sizable projects.  At least three of these instances are
debatable (as evidenced by the ongoing debate).  That can hardly be
interpreted as "too many false positives."

But I'm not at all attached to where to implement it and I'm fully
aware that you have a much better idea than me what's the appropriate
place for it.  I'll be just as happy if it's done in a pass of its
own just as long as it gives users what they've been asking for.


None look like real bugs to me.


They do to me.  There are calls in gengtype.c to a function decorated
with attribute nonnull (lbasename) that pass to it a pointer that's
potentially null.  For example below.  get_input_file_name returns


Most pointers passed to functions with nonnull attributes are, from the
compiler POV, potentially NULL.  Usually the compiler just can't prove it
can't be non-NULL, it is an exception if it can.
If you have a generic function that sometimes can be called with NULL (or
some other "failure" argument) and in that case return NULL, and for valid
arguments it guarantees returning non-NULL (and IMHO the gengtype functions
we talk about fall into that category), then it is not a bug to use this
function and pass the result to functions with nonnull arguments if the
programmer knows it just will not happen.  Forcing the programmer to
workaround dubious warnings by throwing in not very portable attributes
everywhere and duplicating functions, so that one copy can be
returns_nonnull and requiring non-NULL argument and another copy allow
NULL argument and allowing NULL returns is just a nightmare we IMHO don't
want to throw at users.  If they want to do it, sure, they can, but we
shouldn't force them into that.


I'm not entirely sure I follow your argument here, and not just
because I find your propensity for exaggeration and for pejoratives
distracting.  It seems to me that we simply have different views of
what's a true positive and what's not, and what's useful and what's
not.  That's likely to be the case for many others and I think it
might help to acknowledge that neither one of us is necessarily
100% right or wrong.

In that spirit let me reiterate that I don't insist on the warning
being implemented in any particular area of the compiler, or even
that it necessarily diagnose any of the cases we've been discussing.
If your implementation diagnoses the common cases exercised by the
tests I wrote I have no objection to it (not that objecting would
do me any good).

Martin

Re: Do we really need a CPP manual?

[Jeff Law]

On 12/16/2016 11:01 AM, Sandra Loosemore wrote:

On 12/16/2016 08:45 AM, Joseph Myers wrote:

On Thu, 15 Dec 2016, Sandra Loosemore wrote:


Looking at the structure of the whole manual, though, I see that most of
it is in fact a tutorial on how to use the preprocessor language, like
you would find in a C programming book.  Is this a useful thing for us
to be providing? Offhand I am not sure how up-to-date this material is
or how much of a maintenance burden it is, but it seems peculiar to be
providing such extensive introductory material on the preprocessor when
we don't do that for the C or C++ languages; we assume that people
already know how to program.


There's a "GNU C Reference Manual" for the C language; I've no idea if
it's any good.

https://www.gnu.org/software/gnu-c-manual/

It says "Although normally described in a C language manual, the GNU C
preprocessor has been thoroughly documented in The C Preprocessor, a
separate manual which covers preprocessing for C, C++, and Objective-C
programs, so it is not included here.".

So that manual might be a plausible place for documentation of the
preprocessor language as a whole (having excluded such documentation on
the basis of it being covered in the CPP manual), although since it's
strictly a reference that doesn't answer what to do with tutorial
content.


This document also looks very bit-rotten:  "By default, GCC will compile
code as C89 plus GNU-specific extensions. [...]"

TBH, I have no interest in rewriting/maintaining C language manuals or
tutorials.  :-(  Given that there's resistance to removing the existing
CPP tutorial material entirely, I'll try to come up with some other plan
for leaving that part of the CPP manual as-is while addressing the
bit-rot in the options, etc, probably involving more/better use of
shared include files.
That's likely the manual RMS kept asking folks (semi-privately) to 
review.  My response was consistently that such review should happen 
publicly, which RMS opposed for reasons I don't recall.


I don't see that manual as part of the GCC project and I certainly would 
understand a disinterest in reviewing/rewriting C language manuals and 
tutorials :-)


jeff

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Fri, Dec 16, 2016 at 5:50 PM, Dominique d'Humières
 wrote:
> Hi Janne,
>
> I have applied your two patches and found that I had to skip the patches for 
> resolve.c and match.c due to the errors
>
> ../../p_work/gcc/fortran/resolve.c: In function 'void 
> resolve_select_type(gfc_code*, gfc_namespace*)':
> ../../p_work/gcc/fortran/resolve.c:8731:58: error: format '%lld' expects 
> argument of type 'long long int', but argument 4 has type 'long int' 
> [-Werror=format=]
>   gfc_basic_typename (c->ts.type), charlen, c->ts.kind);
>
> and
>
> ../../p_work/gcc/fortran/match.c: In function 'gfc_symtree* 
> select_intrinsic_set_tmp(gfc_typespec*)':
> ../../p_work/gcc/fortran/match.c:5786:55: error: format '%lld' expects 
> argument of type 'long long int', but argument 4 has type 'long int' 
> [-Werror=format=]
>gfc_basic_typename (ts->type), charlen, ts->kind);
>

Oh, blast. Of course you're right, from the second patch, the part
that touched resolve.c and match.c are incorrect.

> while the patch for dump-parse-tree.c was needed.
>
> With the patches applied I see several failures in the test suite compiled 
> with ‘-m64 -flto’, but not with ‘-m32 -flto’ of the kind

Ok, thanks for the hint. I haven't tested with -flto.  Do you just run
it with something like

CFLAGS="-flto" make -j $NCPUS check-fortran

or how do you do it?

I don't have lldb, but I guess I can see roughly the same with gdb..

>
> [Book15] f90/bug% gfc 
> /opt/gcc/work/gcc/testsuite/gfortran.dg/char_result_1.f90 -flto -c
> [Book15] f90/bug% lldb 
> /opt/gcc/gcc7w/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/lto1
> (lldb) target create 
> "/opt/gcc/gcc7w/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/lto1"
> Current executable set to 
> '/opt/gcc/gcc7w/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/lto1' (x86_64).
> (lldb) run char_result_1.o
> Process 1310 launched: 
> '/opt/gcc/gcc7w/libexec/gcc/x86_64-apple-darwin16.1.0/7.0.0/lto1' (x86_64)
> Reading object files: char_result_1.o {GC start 2195k}
> Reading the callgraph
> Merging declarations
> Reading summaries
> Reading function bodies:
> Performing interprocedural optimizations
>
>   Assembling functions:
> f2 f1 double test 
> MAIN__Process 1310 stopped
> * thread #1: tid = 0x54ac, 0x0001008f76cf 
> lto1`lto_input_tree_ref(ib=, data_in=0x000142621090, 
> fn=0x, tag=) + 127 at lto-streamer-in.c:332, 
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
> address=0x18)
> frame #0: 0x0001008f76cf lto1`lto_input_tree_ref(ib=, 
> data_in=0x000142621090, fn=0x, tag=) + 127 
> at lto-streamer-in.c:332
>329
>330  case LTO_ssa_name_ref:
>331ix_u = streamer_read_uhwi (ib);
> -> 332result = (*SSANAMES (fn))[ix_u];
>333break;
>334
>335  case LTO_field_decl_ref:
> (lldb) bt
> * thread #1: tid = 0x54ac, 0x0001008f76cf 
> lto1`lto_input_tree_ref(ib=, data_in=0x000142621090, 
> fn=0x, tag=) + 127 at lto-streamer-in.c:332, 
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
> address=0x18)
>   * frame #0: 0x0001008f76cf lto1`lto_input_tree_ref(ib=, 
> data_in=0x000142621090, fn=0x, tag=) + 127 
> at lto-streamer-in.c:332
> frame #1: 0x0001008f78f1 lto1`lto_input_tree_1(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090, tag=, hash=) + 177 at 
> lto-streamer-in.c:1446
> frame #2: 0x0001008f7cb8 lto1`lto_input_tree(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090) + 88 at lto-streamer-in.c:1492
> frame #3: 0x000100ce8b43 
> lto1`streamer_read_tree_body(lto_input_block*, data_in*, tree_node*) + 51 at 
> tree-streamer-in.c:893
> frame #4: 0x000100ce8b10 
> lto1`streamer_read_tree_body(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090, expr=0x000143944af0) + 2096
> frame #5: 0x0001008f7110 
> lto1`::lto_read_tree_1(ib=0x7fff5fbfeeb0, data_in=0x000142621090, 
> expr=0x000143944af0) + 32 at lto-streamer-in.c:1333
> frame #6: 0x0001008f78b9 lto1`lto_input_tree_1(lto_input_block*, 
> data_in*, LTO_tags, unsigned int) + 38 at lto-streamer-in.c:1363
> frame #7: 0x0001008f7893 lto1`lto_input_tree_1(lto_input_block*, 
> data_in*, LTO_tags, unsigned int) + 20
> frame #8: 0x0001008f787f lto1`lto_input_tree_1(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090, tag=, hash=2871463685) + 63
> frame #9: 0x0001008f7c03 lto1`lto_input_scc(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090, len=0x7fff5fbfede8, 
> entry_len=0x7fff5fbfedec) + 371 at lto-streamer-in.c:1387
> frame #10: 0x0001008f7c91 lto1`lto_input_tree(ib=0x7fff5fbfeeb0, 
> data_in=0x000142621090) + 49 at lto-streamer-in.c:1490
> frame #11: 0x0001008f8d93 
> lto1`::lto_read_body_or_constructor(file_data=0x000143721000, 
> data=, node=, 
> section_type=LTO_section_function_body) + 931 at 

Re: using C++ STL containers in GCC/gfortran source code

[Jakub Jelinek]

On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote:
> To get to more specific questions ...
> 
> > Basically the only STL construct used in the Fortran FE right now
> > seems to be std::swap, and a single instance of std::map in
> > trans-common.c.
> 
> I see that fortran/trans-common.c has:
> 
> #define INCLUDE_MAP
> 
> and apparently there is also a INCLUDE_STRING macro. I guess if I want
> to use std::string I don't #include , but #define
> INCLUDE_STRING, right? Why are those macros needed, exactly?

They are needed because system.h poisons lots of things, including malloc
etc.  So including system headers after system.h is problematic.

That said, using std::string for what you talk in the PR would make it
impossible to translate it, if you build a sentence as:
  ss << "Argument " << something () << " and '" << something_else () << "'";
then our framework can't deal with that, translating portions of a sentence
is not going to be useful for many languages.
Using *printf or similar formatting strings allows the translator to see
the whole sentence with arguments, and e.g. when needed can swap
some arguments using %4$s syntax etc.

Jakub

Re: [PATCH 0/4] Improve DSE implementation

[Jeff Law]

On 12/16/2016 06:32 AM, Richard Biener wrote:

On Fri, Dec 16, 2016 at 2:54 AM, Jeff Law  wrote:

This is a 4 part patchkit to address various deficiencies in our DSE
implementation.

BZ33562 was the inspiration for this work.  33562 is a low priority
regression that's been around for a long time.  Patch #1 addresses 33562,
"aggregate DSE disabled" and also implements trimming of complex assignment
when just one half of it is dead.

The discussions last year with Richi, reviewing of bugs in both LLVM and
GCC's databases and code instrumentation resulted in patches 2-4.

Patch #2 implements trimming of CONSTRUCTOR initializations.  This is
61912/77485.  This gets the most static hits of all the improvements.

Patch #3 implements trimming of mem* calls.  We trim from the front or back
of the store.This doesn't hit as much as #2, but still happens quite
often.  There is no BZ for this deficiency.

Patch #4 adds the ability to look through loads which may read from the same
memory as the potentially dead store, but which can be proven only read from
currently dead bytes within the object.  This hits just once in the compiler
& runtime libraries.  But it does hit often in the libstdc++ testsuite.
There is no BZ for this deficiency.


There's dependencies as we walk forward in the patch kits.  Each patch has
been bootstrapped & tested with its previous patch(es).

There is much more that could be done beyond the series of 4 patches in this
patchkit.  Richi has pointed out that SRA and DSE could probably share a lot
of analysis and transformation code.  There may even be advantages to having
the two optimizations integrated into a single pass.  I haven't investigated
any of that yet (though we are using a bit of code from SRA in this kit).


Yes, see also PR78821, similar other passes are bswap detection and
store merging.  Basically all passes that find "related" loads/stores.
I suppose
rather than fully merging the passes but trying to share some analysis code
and data structures would be a good start (though at the same time you'd
probably rewrite most of those passes).
Certainly the first step would be to share analysis, data structures and 
likely some manipulation routines.





We also need to look at store sinking again.  I saw a patch from Richi back
in July looked reasonable at a high level and would likely allow resolution
of a multiple BZs.


Yeah, it had some fallout / pass ordering issue and I never went back to
it (being also a very simplistic implementation).

Figured it was something like that.

ISTM that store sinking isn't radically different than other cases where 
we want to sink through PHIs.  ISTM that a single driver which could 
sink stores, arithmetic/logicals, whatever would be in order.  It'd be a 
worklist algorithm over PHI nodes since sinking stores through a PHI may 
in turn allow it to sink further.


The question in my mind for stores is do we allow the addresses to vary 
or just the object stored?  We could actually support both in many cases.


Jeff

Re: Do we really need a CPP manual?

[Sandra Loosemore]

On 12/16/2016 08:45 AM, Joseph Myers wrote:

On Thu, 15 Dec 2016, Sandra Loosemore wrote:


Looking at the structure of the whole manual, though, I see that most of
it is in fact a tutorial on how to use the preprocessor language, like
you would find in a C programming book.  Is this a useful thing for us
to be providing? Offhand I am not sure how up-to-date this material is
or how much of a maintenance burden it is, but it seems peculiar to be
providing such extensive introductory material on the preprocessor when
we don't do that for the C or C++ languages; we assume that people
already know how to program.


There's a "GNU C Reference Manual" for the C language; I've no idea if
it's any good.

https://www.gnu.org/software/gnu-c-manual/

It says "Although normally described in a C language manual, the GNU C
preprocessor has been thoroughly documented in The C Preprocessor, a
separate manual which covers preprocessing for C, C++, and Objective-C
programs, so it is not included here.".

So that manual might be a plausible place for documentation of the
preprocessor language as a whole (having excluded such documentation on
the basis of it being covered in the CPP manual), although since it's
strictly a reference that doesn't answer what to do with tutorial content.


This document also looks very bit-rotten:  "By default, GCC will compile 
code as C89 plus GNU-specific extensions. [...]"


TBH, I have no interest in rewriting/maintaining C language manuals or 
tutorials.  :-(  Given that there's resistance to removing the existing 
CPP tutorial material entirely, I'll try to come up with some other plan 
for leaving that part of the CPP manual as-is while addressing the 
bit-rot in the options, etc, probably involving more/better use of 
shared include files.


-Sandra

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78835

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I have once written:
--- gcc/dwarf2out.c.jj  2016-10-21 18:40:34.0 +0200
+++ gcc/dwarf2out.c 2016-10-21 19:36:28.622894699 +0200
@@ -28399,16 +28399,23 @@ resolve_addr (dw_die_ref die)
&& DECL_ABSTRACT_ORIGIN (tdecl) == NULL_TREE
&& (cdie = lookup_context_die (DECL_CONTEXT (tdecl
  {
-   /* Creating a full DIE for tdecl is overly expensive and
-  at this point even wrong when in the LTO phase
-  as it can end up generating new type DIEs we didn't
-  output and thus optimize_external_refs will crash.  */
-   tdie = new_die (DW_TAG_subprogram, cdie, NULL_TREE);
-   add_AT_flag (tdie, DW_AT_external, 1);
-   add_AT_flag (tdie, DW_AT_declaration, 1);
-   add_linkage_attr (tdie, tdecl);
-   add_name_and_src_coords_attributes (tdie, tdecl);
-   equate_decl_number_to_die (tdecl, tdie);
+   dw_die_ref pdie = cdie;
+   /* Make sure we don't add these DIEs into type units.  */
+   while (pdie && pdie->die_tag != DW_TAG_type_unit)
+ pdie = pdie->die_parent;
+   if (pdie == NULL)
+ {
+   /* Creating a full DIE for tdecl is overly expensive and
+  at this point even wrong when in the LTO phase
+  as it can end up generating new type DIEs we didn't
+  output and thus optimize_external_refs will crash.  */
+   tdie = new_die (DW_TAG_subprogram, cdie, NULL_TREE);
+   add_AT_flag (tdie, DW_AT_external, 1);
+   add_AT_flag (tdie, DW_AT_declaration, 1);
+   add_linkage_attr (tdie, tdecl);
+   add_name_and_src_coords_attributes (tdie, tdecl);
+   equate_decl_number_to_die (tdecl, tdie);
+ }
  }
if (tdie)
  {
for this, but am not really sure what is right.  Basically, for
DW_TAG_call_site we sometimes want to refer to a DIE that isn't included,
creating it on the fly outside of type units works, inside of type units is
harder (but I'm afraid I don't know the type units code too much to even know
what should be emitted then).  So the above patch just pessimizes the call site
info in that case rather than ICEing.

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Fri, Dec 16, 2016 at 5:34 PM, Andre Vehreschild  wrote:
> Hi Janne, hi all,
>
> as promised please find attached the change from int32 to size_t for the
> caf-libraries. Because the caf-libraries do not require special notions
> indicated by negative values I went for using size_t there. I assume this will
> be easier to keep in sync for all caf-libraries, because the size_t is
> available on all modern platforms. I also took the liberty to fix the
> specifiers in trans-decl for the caf-function-declarations and update the
> documentation on the caf-functions in gfortran.texi where some parameters 
> where
> missing.
>
> These additional changes bootstrap fine and induce no new regressions on
> x86_64-linux/f23.

I think you should use build_zero_cst(size_type_node) instead of
size_zero_node as size_zero_node is of type sizetype which is not the
same as size_type_node. Otherwise looks good.

And yes, I think it makes sense to use size_t directly instead of
introducing the GFortran specific gfc_charlen_type typedef.

> I am still not sure, whether we shouldn't address the regression in
> allocate_deferred_char_scalar_1. I did some research, but could not yet come 
> to
> a practical solution. The backend somehow deduces that the memory pointed to
> has size 5 only. But I haven't found a way to do this in the front end.
>
> Comments on these changes?
>
> - Andre
>
> On Tue, 13 Dec 2016 21:08:51 +0200
> Janne Blomqvist  wrote:
>
>> On Mon, Dec 12, 2016 at 9:39 PM, Janne Blomqvist
>>  wrote:
>> > On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild  wrote:
>> >> Hi Janne,
>> >>
>> >> I found that you are favoring build_int_cst (size_type_node, 0) over
>> >> size_zero_node. Is there a reason to this?
>> >
>> > Yes. AFAIU size_zero_node is a zero constant for sizetype which is not
>> > the same as size_type_node.
>> >
>> > AFAIK the difference is that size_type_node is the C size_t type,
>> > whereas sizetype is a GCC internal type used for address expressions.
>> > On a "normal" target I understand that they are the same size, but
>> > there are some slight differences in semantics, e.g. size_type_node
>> > like C unsigned integer types is defined to wrap around on overflow
>> > whereas sizetype is undefined on overflow.
>> >
>> > I don't know if GCC supports some strange targets with some kind of
>> > segmented memory where the size of sizetype would be different from
>> > size_type_node, but I guess it's possible in theory at least.
>> >
>> > That being said, now that you mention in I should be using
>> > build_zero_cst (some_type_node) instead of
>> > build_int_cst(some_type_node, 0). There's also build_one_cst that I
>> > should use.
>> >
>> >> Furthermore did I have to patch this:
>> >>
>> >> diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
>> >> index 585f25d..f374558 100644
>> >> --- a/gcc/fortran/dump-parse-tree.c
>> >> +++ b/gcc/fortran/dump-parse-tree.c
>> >> @@ -465,7 +465,7 @@ show_expr (gfc_expr *p)
>> >>   break;
>> >>
>> >> case BT_HOLLERITH:
>> >> - fprintf (dumpfile, "%dH", p->representation.length);
>> >> + fprintf (dumpfile, "%zdH", p->representation.length);
>> >>   c = p->representation.string;
>> >>   for (i = 0; i < p->representation.length; i++, c++)
>> >> {
>> >>
>> >> to bootstrap on x86_64-linux/f23.
>> >
>> > Ah, thanks for the catch. I'll fix it by using HOST_WIDE_INT_PRINT_DEC
>> > since I'll have to change gfc_charlen_t to be a typedef form
>> > HOST_WIDE_INT (see my answer to FX).
>> >
>> >> And I have this regression:
>> >>
>> >> FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03   -O1  (test for
>> >> excess errors)
>> >>
>> >> allocate_deferred_char_scalar_1.f03:184:0:
>> >>
>> >>  p = '12345679'
>> >>
>> >> Warning: '__builtin_memcpy' writing 8 bytes into a region of size 5
>> >> overflows the destination [-Wstringop-overflow=]
>> >>  allocate_deferred_char_scalar_1.f03:242:0:
>> >>
>> >>  p = 4_'12345679'
>> >>
>> >> Warning: '__builtin_memcpy' writing 32 bytes into a region of size 20
>> >> overflows the destination [-Wstringop-overflow=]
>> >
>> > I'm seeing that too, but I assumed they would be fixed by Paul's
>> > recent patch which I don't yet have in my tree yet due to the git
>> > mirror being stuck..
>> >
>> >> Btw, the patch for changing the ABI of the coarray-libs is already nearly
>> >> done. I just need to figure that what the state of regressions is with and
>> >> without my change.
>> >
>> > Thanks.
>> >
>> > I'll produce an updated patch with the changes discussed so far.
>> >
>> >
>> > --
>> > Janne Blomqvist
>>
>> Hi,
>>
>> attached is the updated patch that applies on top of the original. I
>> didn't do the charlen_zero_node etc, I just fixed the relatively few
>> places in my previous patch rather than everywhere in the entire
>> frontend.
>>
>> Now that the git mirror is 

Re: using C++ STL containers in GCC/gfortran source code

[Janus Weil]

To get to more specific questions ...

> Basically the only STL construct used in the Fortran FE right now
> seems to be std::swap, and a single instance of std::map in
> trans-common.c.

I see that fortran/trans-common.c has:

#define INCLUDE_MAP

and apparently there is also a INCLUDE_STRING macro. I guess if I want
to use std::string I don't #include , but #define
INCLUDE_STRING, right? Why are those macros needed, exactly?

Cheers,
Janus

Re: using C++ STL containers in GCC/gfortran source code

[Pedro Alves]

On 12/16/2016 05:33 PM, Janus Weil wrote:

> "You would need to make sure it uses a xmalloc based allocator first
> or at least calls xmalloc_failed upon allocation failure, otherwise it
> will be a serious regression."
> 
> I'm really not an expert on GCC's memory management principles and how
> it uses xmalloc over malloc. I'd love to hear further comments on the
> above sentence (e.g. whether that is really necessary, and if yes, how
> to accomplish it). 

I gave a suggestion in the PR.

Basically, you can replace the global operator new to call xmalloc
instead of malloc.  See the GDB url in the PR for an example.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822#c19

> And in particular: How do the current uses of
> std::string in GCC deal with this problem? (Do they?)

Doesn't look like they do.

Thanks,
Pedro Alves

Re: [PATCH] libstdc++: Allow using without lock free atomic int

[Jonathan Wakely]

On 09/11/16 23:26 +0200, Pauli wrote:

Compiling programs using std::future for old arm processors fails. The
problem is caused by preprocessor check for atomic lock free int.

Future can be changed to work correctly without lock free atomics with
minor changes to exception_ptr implementation.

Without lock free atomics there is question if deadlock can happen. But
atomic operations can't call outside code preventing any ABBA or
recursive mutex acquiring deadlocks.
Deadlock could happen if throwing an exception or access
is_lock_free() == false atomic from asynchronous signal handler.
Throwing from signal handler is undefined behavior. I don't know about
accessing atomics from asynchronous signal handler but that feels like
undefined behavior if is_lock_free returns false.

Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

differences to current if atomic builtins available:
* Race detector annotations that are empty by default
* Check for __gthread_active_p
* Generate x86 code uses xadd instead of xsub
This makes code a bit worse. But problem is duplicated to any other user
of __exchange_and_add. The internal API implementation should be fixed
to generate better code for all cases. But that is a follow up patch.


I'd prefer to do it so we don't change anything for the targets that
already work. Your follow-up patch missed the deadline for GCC 7 and
so will have to wait for GCC 8 now, and we don't want to pessimize
x86.

Also, I think your patch actually breaks some GNU/Linux targets,
because you removed the  header from
, which means that in libsupc++/guard.cc the macro
ATOMIC_INT_LOCK_FREE is no longer defined, and so _GLIBCXX_USE_FUTEX
doesn't get defined. Now arguably guard.cc should have been including
the header directly, but it still shows why such an invasive patch is
a bad idea at this stage of the GCC 7 process.

The attached patch attempts to make exception propagation work for all
targets, without changing anything if it already works.

Do you see any problems with this alternative approach?
Could you please test it for armv5te?

It passes all tests for x86_64-linux and ppc64le-linux.

For your follow-up patch, do you already have a copyright assignment
for contributions to GCC? We'll probably need that before it can be
accepted. We don't need one for this patch, because what remains of
your original patch is just the testsuite changes, which are
mechanical and not copyrightable.

commit e81e908deb699886e65cb4d614f6a0a1cf54662f
Author: Jonathan Wakely 
Date:   Fri Dec 16 15:22:21 2016 +

PR64735 support exception propagation without atomics

2016-11-09  Pauli Nieminen  
	Jonathan Wakely  

	PR libstdc++/64735
	* include/std/future: Remove check for ATOMIC_INT_LOCK_FREE
	* libsupc++/eh_atomics.h: New file for internal use only.
	(__eh_atomic_inc, __eh_atomic_dec): New.
	* libsupc++/eh_ptr.cc (exception_ptr::_M_addref)
	(exception_ptr::_M_release) (__gxx_dependent_exception_cleanup)
	(rethrow_exception): Use eh_atomics.h reference counting helpers.
	* libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise.
	* libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise.
	* libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE.
	* libsupc++/exception_ptr.h: Likewise.
	* libsupc++/guard.cc: Include header for ATOMIC_INT_LOCK_FREE macro.
	* libsupc++/nested_exception.cc: Remove check for
	ATOMIC_INT_LOCK_FREE.
	* libsupc++/nested_exception.h: Likewise.
	* src/c++11/future.cc: Likewise.
	* testsuite/18_support/exception_ptr/*: Remove atomic builtins checks.
	* testsuite/18_support/nested_exception/*: Likewise.
	* testsuite/30_threads/async/*: Likewise.
	* testsuite/30_threads/future/*: Likewise.
	* testsuite/30_threads/headers/future/types_std_c++0x.cc: Likewise.
	* testsuite/30_threads/packaged_task/*: Likewise.
	* testsuite/30_threads/promise/*: Likewise.
	* testsuite/30_threads/shared_future/*: Likewise.

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index 8ba1306..b83d74b 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -192,8 +192,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 future<__async_result_of<_Fn, _Args...>>
 async(_Fn&& __fn, _Args&&... __args);
 
-#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \
-  && (ATOMIC_INT_LOCK_FREE > 1)
+#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
 
   /// Base class and enclosing scope.
   struct __future_base
@@ -1751,7 +1750,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #endif // _GLIBCXX_ASYNC_ABI_COMPAT
 #endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1
-   // && ATOMIC_INT_LOCK_FREE
 
   // @} group futures
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/libsupc++/eh_atomics.h b/libstdc++-v3/libsupc++/eh_atomics.h

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817

--- Comment #19 from Martin Sebor  ---
(In reply to dave.anglin from comment #18)
> The change didn't fix build on hppa-linux:

This should be fixed in the patch referenced in comment #16, though the patch
is yet to be reviewed and judging by the lively debate about the original
commit that introduced the warning it's not entirely clear if it will be
necessary.

[PATCH] noipa attribute (was Re: How to avoid constant propagation into functions?)

[Jakub Jelinek]

Hi!

On Fri, Dec 16, 2016 at 04:53:07PM +0100, Martin Jambor wrote:
> On Fri, Dec 16, 2016 at 02:31:48PM +0100, Jakub Jelinek wrote:
> > Suggestions how to test that IPA-SRA and IPA-PTA aren't happening?
> > Anything else we need to cover?
> I would use some test from gcc/testsuite/gcc.dg/ipa/ipa-sra-*.c, add
> the attribute and negate the scan-dump test.

Thanks.  So I've included a test also for IPA SRA (which worked) and IPA PTA
(which didn't, so I had to change 2 further spots in
tree-ssa-structalias.c).  Makes me wonder if we don't want to cache the
noipa attribute in a cgraph node bit, Honza?

Except for the tree-ssa-structalias.c changes the patch has been
bootstrapped/regtested on x86_64-linux and i686-linux.

2016-12-16  Jakub Jelinek  

* attribs.c (decl_attributes): Imply noinline, noclone and no_icf
attributes for noipa attribute.  For naked attribute use
lookup_attribute first before lookup_attribute_spec.
* final.c (rest_of_handle_final): Disable IPA RA for functions with
noipa attribute.
* ipa-visibility.c (non_local_p): Fix comment typos.  Return true
for functions with noipa attribute.
(cgraph_externally_visible_p): Return true for functions with noipa
attribute.
* cgraph.c (cgraph_node::get_availability): Return AVAIL_INTERPOSABLE
for functions with noipa attribute.
* doc/extend.texi: Document noipa function attribute.
* tree-ssa-structalias.c (refered_from_nonlocal_fn): Set *nonlocal_p
also for functions with noipa attribute.
(ipa_pta_execute): Set nonlocal_p also for nodes with noipa attribute.
c-family/
* c-attribs.c (c_common_attribute_table): Add noipa attribute.
(handle_noipa_attribute): New function.
testsuite/
* gcc.dg/attr-noipa.c: New test.
* gcc.dg/ipa/ipa-pta-18.c: New test.
* gcc.dg/ipa/ipa-sra-11.c: New test.

--- gcc/tree-ssa-structalias.c.jj   2016-11-02 10:00:24.0 +0100
+++ gcc/tree-ssa-structalias.c  2016-12-16 18:14:50.039567004 +0100
@@ -7729,7 +7729,8 @@ refered_from_nonlocal_fn (struct cgraph_
   bool *nonlocal_p = (bool *)data;
   *nonlocal_p |= (node->used_from_other_partition
  || node->externally_visible
- || node->force_output);
+ || node->force_output
+ || lookup_attribute ("noipa", DECL_ATTRIBUTES (node->decl)));
   return false;
 }
 
@@ -7789,7 +7790,9 @@ ipa_pta_execute (void)
 constraints for parameters.  */
   bool nonlocal_p = (node->used_from_other_partition
 || node->externally_visible
-|| node->force_output);
+|| node->force_output
+|| lookup_attribute ("noipa",
+ DECL_ATTRIBUTES (node->decl)));
   node->call_for_symbol_thunks_and_aliases (refered_from_nonlocal_fn,
_p, true);
 
--- gcc/attribs.c.jj2016-12-16 16:56:13.892556596 +0100
+++ gcc/attribs.c   2016-12-16 17:55:57.549265043 +0100
@@ -404,8 +404,8 @@ decl_attributes (tree *node, tree attrib
  those targets that support it.  */
   if (TREE_CODE (*node) == FUNCTION_DECL
   && attributes
-  && lookup_attribute_spec (get_identifier ("naked"))
-  && lookup_attribute ("naked", attributes) != NULL)
+  && lookup_attribute ("naked", attributes) != NULL
+  && lookup_attribute_spec (get_identifier ("naked")))
 {
   if (lookup_attribute ("noinline", attributes) == NULL)
attributes = tree_cons (get_identifier ("noinline"), NULL, attributes);
@@ -414,6 +414,23 @@ decl_attributes (tree *node, tree attrib
attributes = tree_cons (get_identifier ("noclone"),  NULL, attributes);
 }
 
+  /* A "noipa" function attribute implies "noinline", "noclone" and "no_icf"
+ for those targets that support it.  */
+  if (TREE_CODE (*node) == FUNCTION_DECL
+  && attributes
+  && lookup_attribute ("noipa", attributes) != NULL
+  && lookup_attribute_spec (get_identifier ("noipa")))
+{
+  if (lookup_attribute ("noinline", attributes) == NULL)
+   attributes = tree_cons (get_identifier ("noinline"), NULL, attributes);
+
+  if (lookup_attribute ("noclone", attributes) == NULL)
+   attributes = tree_cons (get_identifier ("noclone"),  NULL, attributes);
+
+  if (lookup_attribute ("no_icf", attributes) == NULL)
+   attributes = tree_cons (get_identifier ("no_icf"),  NULL, attributes);
+}
+
   targetm.insert_attributes (*node, );
 
   for (a = attributes; a; a = TREE_CHAIN (a))
--- gcc/testsuite/gcc.dg/ipa/ipa-pta-18.c.jj2016-12-16 17:59:17.359672427 
+0100
+++ gcc/testsuite/gcc.dg/ipa/ipa-pta-18.c   2015-12-17 14:49:32.0 
+0100
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fipa-pta -fdump-ipa-pta2-details 
-fdump-tree-fre3-details" } */
+
+static int