[Bug libbacktrace/89273] New: Count inlined functions in skip parm for backtrace_full and backtrace_print

[vries at gcc dot gnu.org]

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

Bug ID: 89273
   Summary: Count inlined functions in skip parm for
backtrace_full and backtrace_print
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

[ Proposed here: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00579.html ]

The btest test-case modified like this:
...
diff --git a/libbacktrace/btest.c b/libbacktrace/btest.c
index b1c2a2a860d..0925882aed1 100644
--- a/libbacktrace/btest.c
+++ b/libbacktrace/btest.c
@@ -140,7 +140,7 @@ f13 (int f1line, int f2line)
   data.failed = 0;

   f3line = __LINE__ + 1;
-  i = backtrace_full (state, 0, callback_one, error_callback_one, );
+  i = backtrace_full (state, 1, callback_one, error_callback_one, );

   if (i != 0)
 {
@@ -148,9 +148,9 @@ f13 (int f1line, int f2line)
   data.failed = 1;
 }

-  check ("test2", 0, all, f3line, "f13", "btest.c", );
-  check ("test2", 1, all, f2line, "f12", "btest.c", );
-  check ("test2", 2, all, f1line, "test2", "btest.c", );
+  //check ("test2", 0, all, f3line, "f13", "btest.c", );
+  check ("test2", 0, all, f2line, "f12", "btest.c", );
+  check ("test2", 1, all, f1line, "test2", "btest.c", );

   printf ("%s: backtrace_full inline\n", data.failed ? "FAIL" : "PASS");

...

fails like this:
...
PASS: backtrace_full noinline
test2: [0]: got ../csu/libc-start.c expected btest.c
test2: [0]: got 308 expected 126
test2: [0]: got __libc_start_main expected f12
FAIL: backtrace_full inline
PASS: backtrace_simple noinline
PASS: backtrace_simple inline
PASS: backtrace_syminfo variable
...

This is expected behaviour: "SKIP is the number of frames to skip", so the
inline functions don't count.

But arguably, it would be more intuitive if the skip parameter matched the
reduction in number of callbacks in backtrace_full.

[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||88993

--- Comment #8 from Martin Sebor  ---
The patch I posted for the related pr88993 also relaxes this warning for printf
and fprintf:  https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html

Like in the case of pr88993, the warning is by design and (in my view) makes
sense for sprintf but it's not very useful for the other functions where very
little code worries about exceeding these limits (or even cares about the
functions failing as they can for many other reasons).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
[Bug 88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc
limits

[Bug c++/89244] __builtin_is_constant_evaluated not documented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2019-02-10
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
As bug 88977 shows, people use the built-in directly; sooner or later, they
always do, whether or not the built-ins are intended to be.   Before confirming
that bug I went looking for its documentation to make sure I wasn't missing
something and found none, so all I had to go on was the C++ proposal.

GCC documents the vast majority of built-ins, whether or not they are meant to
be used directly.  There are countless examples, including the atomic
built-ins,  __builtin_setjmp and _longjmp for nonlocal Gotos, or
__builtin_object_size.  The manual even exhaustively lists all the C library
functions that it provides built-ins for, even though there is little reason to
do that.  As Jonathan points out, the C++ Type Traits built-ins are documented
as well.  The target sections of the manual exhaustively enumerate
target-specific intrinsics (regrettably, often without specifying their
semantics) even though there are higher-level APIs that users are expected to
use.

This is all immensely helpful, both to users and to GCC developers.  Let me
take care of adding something for __builtin_is_constant_evaluated.

[Bug lto/89272] [9 Regression] r268728 caused FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o assemble

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-09
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug lto/89272] New: [9 Regression] r268728 caused FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o assemble

[hjl.tools at gmail dot com]

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

Bug ID: 89272
   Summary: [9 Regression] r268728 caused FAIL: g++.dg/lto/pr65316
cp_lto_pr65316_0.o assemble
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r268728 caused:

[hjl@gnu-skx-1 gcc-bisect]$
/export/project/git/gcc-bisect/master/268728/bld/gcc/testsuite/g++/../../xg++
-B/export/project/git/gcc-bisect/master/268728/bld/gcc/testsuite/g++/../../
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -nostdinc++
-I/export/project/git/gcc-bisect/master/268728/bld/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/project/git/gcc-bisect/master/268728/bld/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/project/git/gcc-bisect/gcc/libstdc++-v3/libsupc++
-I/export/project/git/gcc-bisect/gcc/libstdc++-v3/include/backward
-I/export/project/git/gcc-bisect/gcc/libstdc++-v3/testsuite/util
-fmessage-length=0 -flto -std=c++11 -g2 -fno-lto-odr-type-merging -O2
-Wno-return-type -c -o cp_lto_pr65316_0.o
/export/project/git/gcc-bisect/gcc/gcc/testsuite/g++.dg/lto/pr65316_0.C
during IPA pass: visibility
/export/project/git/gcc-bisect/gcc/gcc/testsuite/g++.dg/lto/pr65316_0.C:144:1:
internal compiler error: in type_in_anonymous_namespace_p, at ipa-utils.h:221
0xd84e2a type_in_anonymous_namespace_p(tree_node const*)
../../../../gcc/gcc/ipa-utils.h:221
0x1098cbe type_all_ctors_visible_p
../../../../gcc/gcc/ipa-devirt.c:254
0x1098ce8 type_possibly_instantiated_p
../../../../gcc/gcc/ipa-devirt.c:266
0x10a51a5 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../../../gcc/gcc/ipa-devirt.c:3344
0xd84b13 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../../../gcc/gcc/ipa-utils.h:118
0x10fbedc walk_polymorphic_call_targets
../../../../gcc/gcc/ipa.c:183
0x10fca44 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../../../gcc/gcc/ipa.c:427
0x12a9ac5 execute_todo
../../../../gcc/gcc/passes.c:2045
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-skx-1 gcc-bisect]$

[Bug c/89051] -Wno-error= does not work for warning groups

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
LangEnabledBy is used by optc-gen.awk to generate options.c with calls like
those below.  Other than that, I don't think GCC has an internal data structure
to represent this relationship (one that could be queried to give a list of
other options that -Wimplicit controls).  But I'm by no means an expert on
option processing.

case OPT_Wimplicit:
  if (!opts_set->x_warn_implicit_function_declaration)
handle_generated_option (opts, opts_set,
 OPT_Wimplicit_function_declaration, NULL,
value,
 lang_mask, kind, loc, handlers, true, dc);
  if (!opts_set->x_warn_implicit_int)
handle_generated_option (opts, opts_set,
 OPT_Wimplicit_int, NULL, value,
 lang_mask, kind, loc, handlers, true, dc);
  break;

[Bug rtl-optimization/89271] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Known to work||8.0
Version|unknown |9.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug rtl-optimization/89271] New: gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

[segher at gcc dot gnu.org]

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

Bug ID: 89271
   Summary: gcc.target/powerpc/vsx-simode2.c stopped working in
GCC 9
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

In GCC 8 and earlier, this generates

mtvsrwz 32,3
#APP
 # 10 "vsx-simode2.c" 1
xxlor 32,32,32  # v, v constraints
 # 0 "" 2
#NO_APP
mfvsrwz 3,32
blr

but in GCC 9 it is

std 3,-16(1)
ori 2,2,0
lwz 9,-12(1)
mtvsrwz 32,9
#APP
 # 10 "vsx-simode2.c" 1
xxlor 32,32,32  # v, v constraints
 # 0 "" 2
#NO_APP
mfvsrwz 3,32
blr

and soon it will be

    std 3,-16(1)
    addi 9,1,-12
        lxsiwzx 32,0,9
blr

[ Hrm, no ori 2,2,0?  And it is better to do li 9,-12 etc. ]

This is because IRA does

 r125: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS

   a1(r125,l0) costs: BASE_REGS:14004,14004 GENERAL_REGS:14004,14004-
   LINK_REGS:24010,24010 CTR_REGS:24010,24010 LINK_OR_CTR_REGS:24010,24010-
   SPEC_OR_GEN_REGS:24010,24010 MEM:12000,12000

and it then chooses disposition mem for r125.

In GCC 8 and before combine already has decided to use GPR3 (the first
argument register) for this, so there was no RA here before.

[Bug fortran/71703] [7/8/9 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #11 from Thomas Koenig  ---
Part of the problem seems to be in gfc_conv_same_type_as, where
we have

  if (UNLIMITED_POLY (b))
{
  tmp = gfc_class_vptr_get (b->symtree->n.sym->backend_decl);
  condb = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
   tmp, build_int_cst (TREE_TYPE (tmp), 0));
}

(same for a above).

This looks at the backend_decl only, without following the
reference in some way.

Here is what the backend_decl looks like:

(gdb) call debug_tree(b->symtree->n.sym->backend_decl)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x773625e8
fields 
SI a.f90:5:0
size 
unit-size 
align:32 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain >
chain >
used static BLK a.f90:9:0 size  unit-size

align:64 warn_if_not_align:0 context 
initial  chain >

not that I can really read what this is, or what it should be :-|

[Bug ipa/88711] [9 Regression] scan-ipa-dump inline "Inlined tp_sum/

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
> "I committed a patch that causes a regression in the Fortran
>  testsuite.  Clearly, the problem is with Fortran not my patch.
>  I don't care about Fortran or respect those that work on the
>  Fortran FE.  Therefore, I just XFAIL the regressing test
>  case and call it Good(tm)."
> 
> Thanks.
> 
> How about reverting your patch?

The patch fixes obvious bug. That bug made inliner heuristics lucky for
this particular testcase (which was introduced by me because I also do
care about Fortran perfomrance) but also it caused problems elsewhere (I
noticed it while analyzing 10% slowdown of Firefox HTML parser).

There is no way to make inline heuristics perfect for everyone (it would
not be called heuristics then). Sadly I do not see way to improve this
particular testcase without simply increasing inline limits (would
increase code size and make others unhappy), adding some logic telling
inliner that Fortran functions should be inlined more (which was
discussed before but was not considered coolest direction ofthe attack)
or teching inliner to recognize quite complex interaction between
individual functions inlined that is hard to do.

Bumping up --param inline-insns-auto limit helps this particular
testcase.

Honza

[Bug fortran/71066] [7/8/9 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Removing the assert

gcc_assert (loop->dimen == 1);

> $ cat z3.f90
> program p
>real :: a(2,2)[*]
>data a /4*0.0/
> end

just hits a check later on:

d.f90:1:0:

1 | program p
  | 
interner Compiler-Fehler: in trans_array_constructor, bei
fortran/trans-array.c:2556
0x616351 trans_array_constructor
../../trunk/gcc/fortran/trans-array.c:2556
0x616351 gfc_add_loop_ss_code
../../trunk/gcc/fortran/trans-array.c:2869

So, the setup of the loop is wrong earlier.

[Bug c/89270] New: [9 regression] AVR ICE: verify_gimple failed

[gandalf at winds dot org]

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

Bug ID: 89270
   Summary: [9 regression] AVR ICE: verify_gimple failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

I get an ICE on the following code with GCC 9.0.1 20190209 (experimental)
compiled for AVR. Works in GCC 8.x.

void test()
{
  extern const unsigned char __memx __data_load_end;
  __uint24 top=(__uint24)&__data_load_end;
}

# avr-gcc -v -save-temps -mmcu=atmega1284p -c test2.c -o test.o
Using built-in specs.
Reading specs from
/usr/local/avr/lib/gcc/avr/9.0.1/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 9.0.1 20190209 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps'  '-c' '-o' 'test.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/9.0.1/cc1 -E -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test2.c -mn-flash=2
-mno-skip-bug -mmcu=avr51 -fpch-preprocess -o test2.i
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/9.0.1/include
 /usr/local/avr/lib/gcc/avr/9.0.1/include-fixed
 /usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps'  '-c' '-o' 'test.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/9.0.1/cc1 -fpreprocessed test2.i -mn-flash=2
-mno-skip-bug -quiet -dumpbase test2.c -mmcu=avr51 -auxbase-strip test.o
-version -o test2.s
GNU C17 (GCC) version 9.0.1 20190209 (experimental) (avr)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 9.0.1 20190209 (experimental) (avr)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7a3227a0716f5444cb50a3b2fc4e4212
test2.c: In function 'test':
test2.c:1:6: error: invalid types in nop conversion
1 | void test()
  |  ^~~~
long int
const  unsigned char *
_1 = (long int) &__data_load_end;
test2.c:1:6: internal compiler error: verify_gimple failed
0xc5df1d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5094
0x9f42f5 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:13701
0x9f44e4 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:13791
0x86ac77 cgraph_node::analyze()
../../gcc/cgraphunit.c:667
0x86d803 analyze_functions
../../gcc/cgraphunit.c:1126
0x86e4e2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2834

[Bug fortran/71860] [7/8 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  ---
Test cases committed, closing.

Thanks for the bug report!

[Bug fortran/71860] [7/8 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Feb  9 20:09:56 2019
New Revision: 268731

URL: https://gcc.gnu.org/viewcvs?rev=268731=gcc=rev
Log:
2019-02-09  Thomas Koenig  

PR fortran/71860
Backport from trunk
* gfortran.dg/null_10.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/null_10.f90
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/71860] [7/8 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Feb  9 20:07:28 2019
New Revision: 268730

URL: https://gcc.gnu.org/viewcvs?rev=268730=gcc=rev
Log:
2019-02-09  Thomas Koenig  

PR fortran/71860
Backport from trunk
* gfortran.dg/null_10.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/null_10.f90
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug ipa/88711] [9 Regression] scan-ipa-dump inline "Inlined tp_sum/

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Sat, Feb 09, 2019 at 06:12:53PM +, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711
> 
> --- Comment #6 from Jan Hubicka  ---
> Definitly not P1 anymore. The testcase is still not optimized well, but I 
> think
> it falls into the general category that Fotran programming style prefers more
> inlining than C/C++ and it may make sense to declare all Fortran functions
> inline or have some other flag telling middle-end to inline more.
> 

Interesting.  So, my interpretation is 

"I committed a patch that causes a regression in the Fortran
 testsuite.  Clearly, the problem is with Fortran not my patch.
 I don't care about Fortran or respect those that work on the
 Fortran FE.  Therefore, I just XFAIL the regressing test
 case and call it Good(tm)."

Thanks.

How about reverting your patch?

[Bug middle-end/89269] RISC-V stack variable as global variable

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andreas Schwab  ---
The data at 80c00400 is the template from which message is initialized on the
stack.  Nothing ever writes to it.

[Bug c/89269] New: RISC-V stack variable as global variable

[rtos.pharos at outlook dot com]

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

Bug ID: 89269
   Summary: RISC-V stack variable as global variable
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rtos.pharos at outlook dot com
  Target Milestone: ---

Hello all,

I'm working on Pharos operating system
https://sourceforge.net/projects/rtospharos/ (maybe this information could be
useful for debugging the issue).

In RISC-V (riscv64-unknown-elf-gcc) version 8.2.0 the following code:


void aperiodicThread0_0()
{
PharosHwQueueSendR sendResult;
uint8_t message[] = {
0xda , 0x4f , 0xc2 , 4 , 5 , 6 , 7 , 8
};

 .
 . 
 .

}

(the important part is the message variable that is declared on the stack) this
code compiles into:

800013ac:   1101addisp,sp,-32
800013ae:   ec06sd  ra,24(sp)
800013b0:   e822sd  s0,16(sp)
800013b2:   1000addis0,sp,32
PharosHwQueueSendR sendResult;
uint8_t message[] = {
800013b4:   00bff797auipc   a5,0xbff
800013b8:   04c78793addia5,a5,76 # 80c00400

800013bc:   639cld  a5,0(a5)
800013be:   fef43023sd  a5,-32(s0)
0xda , 0x4f , 0xc2 , 4 , 5 , 6 , 7 , 8


That is, the "message" variable is placed after the partition1BssEnd section
(this is defined on the linker script). Even with optimizations (this code was
compiled -O0) this should not occur. In short, I am developing an OS with
everything defined statically, so that at startup the OS already knows where to
place every global variable and we can protect the memory of each
partition/process. If variables that should on stack are placed on a global
section (not even on the partition that they belong to) that screws up the
mechanism.

Best regards,
Pharos Team

[Bug libbacktrace/60240] libbacktrace problems with nested functions

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Ian Lance Taylor  ---
I agree that this example cannot be expected to work.  The docs for
backtrace_pcinfo say that the function works when "Given PC, a program counter
in the current program."  The value (uintptr_t) is not a program counter in
the current program.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #28 from Bernd Edlinger  ---
(In reply to Ramana Radhakrishnan from comment #27)
> (In reply to Bernd Edlinger from comment #25)
> > you might consider adding something like that to your patch:
> > 
> > Index: elf.h
> > ===
> > --- elf.h   (revision 268337)
> > +++ elf.h   (working copy)
> > @@ -64,7 +64,7 @@
> >  %{mapcs-*:-mapcs-%*} \
> >  %(subtarget_asm_float_spec) \
> >  %{mthumb-interwork:-mthumb-interwork} \
> > -%{mfloat-abi=*} %{!mfpu=auto: %{mfpu=*}} \
> > +%{mfloat-abi=*} %{!mfpu=auto: %{!mfpu=none: %{mfpu=*}}} \
> >  %(subtarget_extra_asm_spec)"
> >  #endif
> >  
> > 
> > 
> > otherwise using -mfpu=none won't work on the command line.
> > becuse gas does not understand it.
> 
> Yes, that's what I've been playing with. I've run out of time this week
> because of other work commitments, I hope to get back to this early next
> week.
> 
> Ramana

It is a bit unfortunate that -mfpu= on the command line seems to have
an impact on the eabi_attribute section, while the pragma does not:

  if (TARGET_HARD_FLOAT && TARGET_VFP_SINGLE)
arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);

  if (TARGET_HARD_FLOAT_ABI)
arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);

where TARGET_HARD_FLOAT and TARGET_VFP_SINGLE are defined as follows:

#define TARGET_HARD_FLOAT   (arm_float_abi != ARM_FLOAT_ABI_SOFT\
 && bitmap_bit_p (arm_active_target.isa, \
  isa_bit_vfpv2) \
 && TARGET_32BIT)

#define TARGET_VFP_DOUBLE (bitmap_bit_p (arm_active_target.isa,
isa_bit_fp_dbl))

#define TARGET_VFP_SINGLE (!TARGET_VFP_DOUBLE)


But arm_active_target.isa seems to depend on the effective -mfpu= command line
option, while later in the code generation the same macros are used to
select the use of VFP instructions.

I wonder if it would be better to have an orthogonal way to specify
the used ABI and the used register banks.

So like -mfpu=vfpv3-d16 and -mno-vfp,
where -mfpu= affects the eabi_attribute only
and -mno-vfp makes sure that no VFP registers are used, and, in particular
if functions are defined or called, where the ABI is incompatible because it
passes the values in VFP registers, that should be diagnosed, because it
will not work as expected.

[Bug ipa/88711] [9 Regression] scan-ipa-dump inline "Inlined tp_sum/

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Definitly not P1 anymore. The testcase is still not optimized well, but I think
it falls into the general category that Fotran programming style prefers more
inlining than C/C++ and it may make sense to declare all Fortran functions
inline or have some other flag telling middle-end to inline more.

[Bug d/89177] unaligned memory access in libphobos

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Created attachment 45651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45651=edit
proposed patch

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #34 from Jan Hubicka  ---
Fixed.

[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Jason,
I can avoid the ICE by simply not simplifying contexts for all C++ destructors.
Index: tree.c
===
--- tree.c  (revision 268728)
+++ tree.c  (working copy)
@@ -5772,7 +5772,7 @@ free_lang_data_in_decl (tree decl, struc
  these are needed by devirtualization.  */
   if (TREE_CODE (decl) != FIELD_DECL
   && ((TREE_CODE (decl) != VAR_DECL && TREE_CODE (decl) != FUNCTION_DECL)
-  || !DECL_VIRTUAL_P (decl)))
+  || (!DECL_VIRTUAL_P (decl) && !DECL_CXX_DESTRUCTOR_P (decl
 DECL_CONTEXT (decl) = fld_decl_context (DECL_CONTEXT (decl));
 }

but it seems to me this is more a workaround - if the destructor is virtual, it
should have VIRTUAL flag set. Or is there any reason we want to handle it
differently then any other normal virutal function in the middle-end?

[Bug libstdc++/87809] [8/9 Regression] Can't create empty std::optional>

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb  9 18:01:03 2019
New Revision: 268728

URL: https://gcc.gnu.org/viewcvs?rev=268728=gcc=rev
Log:

PR lto/87809
* tree.c (fld_simplified_type_name): Use DECL_ASSEMBLER_NAME_SET_P
instead of type_with_linkage.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug ipa/88755] [9 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:2513 since r267601

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug ipa/88755] [9 Regression] ICE in compute_fn_summary, at ipa-fnsummary.c:2513 since r267601

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb  9 17:56:22 2019
New Revision: 268727

URL: https://gcc.gnu.org/viewcvs?rev=268727=gcc=rev
Log:

PR ipa/88755
* params.def (uninlined-function-insns, uninlined-function-time,
uninlined-thunk-insns, uninlined-thunk-time): Add artificial upper
bound so we don't get overflows.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def

[Bug c++/89267] [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The trunk has unlike 8.x the first hunk from r268377 which handles
CALL_FROM_THUNK_P elsewhere, and that is where it clears EXPR_LOCATION on the
call too.

[Bug fortran/89077] ICE using * as len specifier for character parameter

[anlauf at gcc dot gnu.org]

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Sat Feb  9 17:25:23 2019
New Revision: 268726

URL: https://gcc.gnu.org/viewcvs?rev=268726=gcc=rev
Log:
2019-02-09  Harald Anlauf  

PR fortran/89077
* resolve.c (gfc_resolve_substring_charlen): Check substring
length for constantness prior to general calculation of length.

PR fortran/89077
* gfortran.dg/substr_simplify.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/substr_simplify.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from acsawdey at gcc dot gnu.org ---
This is fixed in trunk and gcc-8-branch. Hopefully I got this into 8 in time
for it to get into 8.3.

[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion

[acsawdey at gcc dot gnu.org]

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

--- Comment #10 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Sat Feb  9 17:11:06 2019
New Revision: 268725

URL: https://gcc.gnu.org/viewcvs?rev=268725=gcc=rev
Log:
2019-02-09  Aaron Sawdey  

Backported from mainline
2019-02-05  Aaron Sawdey  

PR target/89112
* config/rs6000/rs6000.md (tf_): Generate a local label
for the long branch case.

2019-02-05  Aaron Sawdey  

PR target/89112
* config/rs6000/rs6000-string.c (do_ifelse, expand_cmp_vec_sequence,
expand_compare_loop, expand_block_compare_gpr,
expand_strncmp_align_check, expand_strncmp_gpr_sequence): Insert
REG_BR_PROB notes in inline expansion of memcmp/strncmp. Add
#include "profile-count.h" and "predict.h" for types and functions
needed to work with REG_BR_PROB notes.

2019-02-09  Aaron Sawdey  

* config/rs6000/rs6000-string.c (expand_compare_loop,
expand_block_compare): Insert REG_BR_PROB notes in inline expansion of
memcmp/strncmp.



Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000-string.c
branches/gcc-8-branch/gcc/config/rs6000/rs6000.md

[Bug tree-optimization/89268] [9 Regression] r268689 caused FAIL: gcc.dg/vect/pr79887.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/89268] [9 Regression] r268689 caused FAIL: gcc.dg/vect/pr79887.c

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45650=edit
gcc9-pr89268.patch

Full untested patch.

[Bug tree-optimization/89268] [9 Regression] r268689 caused FAIL: gcc.dg/vect/pr79887.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-09
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I think we want:
--- gcc/tree-if-conv.c.jj   2019-02-08 20:00:40.774827920 +0100
+++ gcc/tree-if-conv.c  2019-02-09 17:35:36.995782510 +0100
@@ -2760,7 +2760,8 @@ version_loop_for_if_conversion (struct l
   new_loop->force_vectorize = false;
   gsi = gsi_last_bb (cond_bb);
   gimple_call_set_arg (g, 1, build_int_cst (integer_type_node,
new_loop->num));
-  preds->safe_push (g);
+  if (preds)
+preds->safe_push (g);
   gsi_insert_before (, g, GSI_SAME_STMT);
   update_ssa (TODO_update_ssa);
   return new_loop;
so that it behaves as before when called from tree-vect-loop.c (preds is NULL).

[Bug ipa/88711] [9 Regression] scan-ipa-dump inline "Inlined tp_sum/

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Sat Feb  9 16:28:45 2019
New Revision: 268723

URL: https://gcc.gnu.org/viewcvs?rev=268723=gcc=rev
Log:

PR ipa/88711
* gfortran.dg/pr79966.f90: Xfail everwyhere.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr79966.f90

[Bug tree-optimization/56457] Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Does this still happen?

[Bug target/48595] score-elf fails to build with --enable-werror-always

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
does this still happen?

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756
Bug 44756 depends on bug 21014, which changed state.

Bug 21014 Summary: read-rtl.c:670: warning: missing sentinel in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21014

   What|Removed |Added

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

[Bug middle-end/21014] read-rtl.c:670: warning: missing sentinel in function call

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #7 from John David Anglin  ---
This doesn't occur anymore.

[Bug fortran/88326] [7/8/9 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|ICE in  |[7/8/9 Regression] ICE in
   |gfc_conv_array_initializer, |gfc_conv_array_initializer,
   |at  |at
   |fortran/trans-array.c:6085  |fortran/trans-array.c:6085

--- Comment #4 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)
> The change occurred between revisions r188694 (2012-06-16, error) and
> r188914 (2012-06-24, ICE).
> 
> Note that the third test in comment 0 compiles with r188694.

A regression (at least this part), then.

[Bug libbacktrace/69314] Use of uninitialised value in libbacktrace/pecoff.c

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Tom de Vries  ---
Fixed in r257040.

https://gcc.gnu.org/ml/gcc-cvs/2018-01/msg00986.html :

Author: ian
Date: Thu Jan 25 02:42:26 2018
New Revision: 257040

URL: https://gcc.gnu.org/viewcvs?rev=257040=gcc=rev
Log:
* pecoff.c (coff_add): Use coff_read4, not memcpy.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/pecoff.c

[Bug tree-optimization/89268] New: [9 Regression] r268689 caused FAIL: gcc.dg/vect/pr79887.c

[hjl.tools at gmail dot com]

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

Bug ID: 89268
   Summary: [9 Regression] r268689 caused FAIL:
gcc.dg/vect/pr79887.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

r268689 caused:

[hjl@gnu-skx-1 gcc-bisect]$ cat gcc/gcc/testsuite/gcc.dg/vect/pr79887.c
/* Test for pr79887.  */
/* { dg-do compile } */
/* { dg-require-effective-target vect_condition } */
/* { dg-additional-options "-fno-trapping-math --param vect-epilogues-nomask=1"
} */
/* { dg-additional-options "-mavx512ifma" { target x86_64-*-* i?86-*-* } } */

void
foo (float a[32], float b[2][32])
{
  int i;
  for (i = 0; i < 32; i++)
a[i] = (b[0][i] > b[1][i]) ? b[0][i] : b[1][i];
}

[hjl@gnu-skx-1 gcc-bisect]$ ./master/268689/usr/bin/gcc -S
gcc/gcc/testsuite/gcc.dg/vect/pr79887.c -mavx512ifma -fno-trapping-math --param
vect-epilogues-nomask=1 -mtune=intel -O3
during GIMPLE pass: vect
gcc/gcc/testsuite/gcc.dg/vect/pr79887.c: In function \u2018foo\u2019:
gcc/gcc/testsuite/gcc.dg/vect/pr79887.c:8:1: internal compiler error:
Segmentation fault
8 | foo (float a[32], float b[2][32])
  | ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-skx-1 gcc-bisect]$

[Bug libbacktrace/60240] libbacktrace problems with nested functions

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||ian at airs dot com,
   ||ian at gcc dot gnu.org,
   ||vries at gcc dot gnu.org
  Component|other   |libbacktrace

--- Comment #1 from Tom de Vries  ---
I can reproduce this.

But, I wonder if this an actual bug, given that the address of the nested
function that is passed as argument to backtrace_pcinfo is either a trampoline
on stack or some function descriptor (
https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html ).

Using a backtrace_print from a nested function works fine.

I propose to mark this resolved-invalid.

[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug c++/86943] [7 Regression] Wrong code when converting stateless generic lambda to function pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||8.2.1
Summary|[7/8 Regression] Wrong code |[7 Regression] Wrong code
   |when converting stateless   |when converting stateless
   |generic lambda to function  |generic lambda to function
   |pointer |pointer

--- Comment #15 from Jakub Jelinek  ---
Fixed for 8.3 too.

[Bug c++/89267] [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-09
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This changed with r268700, the same set of errors/notes is emitted before and
after, but
error: call to non-‘constexpr’ function ‘ [with auto:3 = int]’
used to be emitted on line 11 and now is emitted on line 9 instead.  Note,
trunk emits it on line 11.
Do we want to adjust the testcase, or change something in the compiler?

[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-09
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Goes back a long time, at least to gcc 6.

at least 4.8.

[Bug libbacktrace/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Segher Boessenkool from comment #6)
> please reopen it if it still happens (with trunk or another supported
> version).  Thanks!

And if it still happens, please attach the log for the failing test-case:
btest.log.

Thanks,
- Tom

[Bug c++/89267] New: [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C (test for excess errors)

[hjl.tools at gmail dot com]

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

Bug ID: 89267
   Summary: [8 Regression] FAIL: g++.dg/cpp1z/constexpr-lambda8.C
 (test for excess errors)
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

r268714 gave:

spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test/bld/gcc/testsuite/g++/../../xg++
-B/export/gnu/import/git/gcc-test/bld/gcc/testsuite/g++/../../
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/export/gnu/import/git/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/export/gnu/import/git/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/gcc-test/src-8/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-test/src-8/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-test/src-8/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++17 -S -o constexpr-lambda8.s^M
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:11:27:
error: non-constant condition for static assertion^M
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:11:19:
  in 'constexpr' expansion of 'Fwd.(NC.::operator int (*)(int)(), 3)'^M
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:9:48:
error: call to non-'constexpr' function ' [with auto:3 =
int]'^M
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:9:20:
note: ' [with auto:3 = int]' is not usable as a 'constexpr'
function because:^M
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:9:35:
error: 's' declared 'static' in 'constexpr' context^M
compiler exited with status 1
PASS: g++.dg/cpp1z/constexpr-lambda8.C(test for errors, line 9)
PASS: g++.dg/cpp1z/constexpr-lambda8.C(test for warnings, line 11)
PASS: g++.dg/cpp1z/constexpr-lambda8.C(test for errors, line 11)
FAIL: g++.dg/cpp1z/constexpr-lambda8.C   (test for excess errors)
Excess errors:
/export/gnu/import/git/gcc-test/src-8/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda8.C:9:48:
error: call to non-'constexpr' function ' [with auto:3 = int]'

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[amodra at gcc dot gnu.org]

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

--- Comment #35 from Alan Modra  ---
Author: amodra
Date: Sat Feb  9 12:44:02 2019
New Revision: 268722

URL: https://gcc.gnu.org/viewcvs?rev=268722=gcc=rev
Log:
[RS6000] Correct save_reg_p

PR target/88343
* config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p): Match
logic in rs6000_emit_prologue emitting pic_offset_table setup.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c

[Bug libbacktrace/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Segher Boessenkool  ---
4.8 is no longer supported (and neither are 4.9, 5, or 6).  I'm closing this
bug; please reopen it if it still happens (with trunk or another supported
version).  Thanks!

[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Blocks||19276, 31237

--- Comment #1 from Thomas Koenig  ---
Goes back a long time, at least to gcc 6.

I also think that this is valid code, but if somebody can find
language in the standard that says otherwise, please correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
[Bug 19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237
[Bug 31237] [meta-bug] TRANSFER intrinsic

[Bug fortran/89266] New: ICE with TRANSFER of len=0 character array constructor

[tkoenig at gcc dot gnu.org]

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

Bug ID: 89266
   Summary: ICE with TRANSFER of len=0 character array constructor
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

$ cat tst3.f90 
program test
  implicit none
  integer :: i
  character(*), parameter :: y = ''
  character(*), parameter :: z = transfer ([''], y)
end

$ gfortran tst3.f90 
f951: interner Compiler-Fehler: Speicherzugriffsfehler
0xe24dff crash_signal
../../trunk/gcc/toplev.c:326
0x843411 add_init_expr_to_sym
../../trunk/gcc/fortran/decl.c:1924
0x84c5dd variable_decl
../../trunk/gcc/fortran/decl.c:2864
0x84c5dd gfc_match_data_decl()
../../trunk/gcc/fortran/decl.c:6005
0x8aac50 match_word
../../trunk/gcc/fortran/parse.c:65
0x8aac50 decode_statement
../../trunk/gcc/fortran/parse.c:376
0x8ae6f4 next_free
../../trunk/gcc/fortran/parse.c:1241
0x8ae6f4 next_statement
../../trunk/gcc/fortran/parse.c:1473
0x8afd5a parse_spec
../../trunk/gcc/fortran/parse.c:3865
0x8b257c parse_progunit
../../trunk/gcc/fortran/parse.c:5680
0x8b3923 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6220
0x8fd0af gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204

Variant:

$ cat tst3.f90 
program test
  implicit none
  integer :: i
  character(*), parameter :: y = 'efcdab'
  character(6), save  :: z = transfer ([''], y)
  print *,len(z)
end
$ gfortran tst3.f90 
tst3.f90:1:0:

1 | program test
  | 
interner Compiler-Fehler: in gfc_conv_string_init, bei
fortran/trans-const.c:147
0x6181c5 gfc_conv_string_init(tree_node*, gfc_expr*)
../../trunk/gcc/fortran/trans-const.c:147
0x9412f0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../trunk/gcc/fortran/trans-expr.c:7351
0x928389 gfc_get_symbol_decl(gfc_symbol*)
../../trunk/gcc/fortran/trans-decl.c:1831
0x92aee7 generate_local_decl
../../trunk/gcc/fortran/trans-decl.c:5621
0x8e8622 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:4155
0x92c074 generate_local_vars
../../trunk/gcc/fortran/trans-decl.c:5821
0x92c074 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6465
0x8b3f0e translate_all_program_units
../../trunk/gcc/fortran/parse.c:6134
0x8b3f0e gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6337
0x8fd0af gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204

[Bug c++/87770] [8 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230

[konraddabrowski at yahoo dot co.uk]

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

--- Comment #7 from Konrad Dabrowski  ---
Thank you for fixing this. Would it be possible to backport this patch to the
gcc-8 branch?

[Bug target/89261] ix86_data_alignment has wrong argument type

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to H.J. Lu from comment #0)
> > i386.c has
> > 
> > int
> > ix86_data_alignment (tree type, int align, bool opt)
> > 
> > But "align" passed down is unsigned.
> 
> Where is the bug?
> 
> I don't think anybody passed negative alignment or alignment >= 2G.

This is a valid code:

[hjl@gnu-skx-1 gcc]$ cat /tmp/x.i
typedef double __v2df __attribute__ ((__vector_size__ (16), aligned(1 << 28)));
__v2df foo = { 1.0, 2.0 };
[hjl@gnu-skx-1 gcc]$ gcc -S /tmp/x.i
[hjl@gnu-skx-1 gcc]$ cat x.s
.file   "x.i"
.text
.globl  foo
.data
.align 16    This is wrong.
.type   foo, @object
.size   foo, 16
foo:
.long   0
.long   1072693248
.long   0
.long   1073741824
.ident  "GCC: (GNU) 8.2.1 20190109 (Red Hat 8.2.1-7)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$

[Bug c/89265] Incorrect bitfield type in -Wconversion warnings

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andreas Schwab  ---
.

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

[Bug c/89264] Incorrect bitfield type in -Wconversion warnings

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 89265 has been marked as a duplicate of this bug. ***

[Bug c/89264] New: Incorrect bitfield type in -Wconversion warnings

[pskocik at gmail dot com]

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

Bug ID: 89264
   Summary: Incorrect bitfield type in -Wconversion warnings
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

void f() { struct{ unsigned x:1; }x = { (unsigned){0} }; }

warns about a conversion to `unsigned char:1`. It should say `unsigned int:1`.

[Bug c/89265] New: Incorrect bitfield type in -Wconversion warnings

[pskocik at gmail dot com]

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

Bug ID: 89265
   Summary: Incorrect bitfield type in -Wconversion warnings
   Product: gcc
   Version: 7.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

void f() { struct{ unsigned x:1; }x = { (unsigned){0} }; }

warns about a conversion to `unsigned char:1`. It should say `unsigned int:1`.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #2 from ohaiziejohwahkeezuoz at xff dot cz ---
The main problem is elsewhere (read_cgraph_and_symbols looks just like some
cascading assertion failure because of some other segfault). I recompiled gcc
with -Og -ggdb and managed to produce this backtrace:

Thread 6.1 "lto1-wpa" received signal SIGSEGV, Segmentation fault.
[Switching to process 20627]
0x0090c7ac in is_a_helper::test
(p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/cgraph.h:1953
1953  return p && p->type == SYMTAB_FUNCTION;
(gdb) bt
#0  0x0090c7ac in is_a_helper::test
(p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/cgraph.h:1953
#1  is_a (p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/is-a.h:187
#2  dyn_cast (p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/is-a.h:224
#3  input_node (file_data=file_data@entry=0x770ac000,
ib=ib@entry=0x19ca940, tag=LTO_symtab_unavail_node, nodes=nodes@entry=...)
at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1253
#4  0x00910480 in input_cgraph_1
(file_data=file_data@entry=0x770ac000, ib=ib@entry=0x19ca940) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1556
#5  0x00910a25 in input_symtab () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1864
#6  0x005f6962 in read_cgraph_and_symbols (nfiles=344,
fnames=0x1991aa0) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto/lto.c:2897
#7  0x005f6db8 in lto_main () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto/lto.c:3362
#8  0x00a59b7a in compile_file () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:455
#9  0x00a5bba7 in do_compile () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:2132
#10 0x00a5c120 in toplev::main (this=this@entry=0x7fffd1e6,
argc=, argc@entry=29, argv=,
argv@entry=0x7fffd2e8)
at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:2267
#11 0x011c4c30 in main (argc=29, argv=0x7fffd2e8) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/main.c:39

(gdb) l
1948template <>
1949template <>
1950inline bool
1951is_a_helper ::test (symtab_node *p)
1952{
1953  return p && p->type == SYMTAB_FUNCTION;
1954}
1955
1956/* Report whether or not THIS symtab node is a vriable, aka
varpool_node.  */
1957
(gdb) p p
$1 = (symtab_node *) 0x622e7365646f6e5f
(gdb) p *p
Cannot access memory at address 0x622e7365646f6e5f


Looks like some memory corruption bug.

[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648

[mark at gcc dot gnu.org]

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

--- Comment #7 from Mark Wielaard  ---
Is this a regression that will probably be fixed for GCC 9.1 or should we be
adding workaround to the code.

Currently elfutils won't build on distros that started using the GCC 9.0
prerelease on 32bit architectures (i686, arm32):

BUILDSTDERR: readelf.c: In function 'print_debug_str_section':
BUILDSTDERR: readelf.c:10152:15: error: '%*llx' directive output between 4 and
2147483647 bytes may cause result to exceed 'INT_MAX'
[-Werror=format-overflow=]
BUILDSTDERR: 10152 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits,
(uint64_t) offset, str);
BUILDSTDERR:   |   ^~
BUILDSTDERR: readelf.c:10152:18: note: format string is defined here
BUILDSTDERR: 10152 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits,
(uint64_t) offset, str);
BUILDSTDERR: readelf.c:10152:15: note: directive argument in the range [0,
18446744073709551614]
BUILDSTDERR: 10152 |   printf (" [%*" PRIx64 "]  \"%s\"\n", digits,
(uint64_t) offset, str);
BUILDSTDERR:   |

[Bug fortran/89200] [9 Regression] Erroneous copying of a derived type with a deferred-length character array component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Thanks for the report.

Paul

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 89200, which changed state.

Bug 89200 Summary: [9 Regression] Erroneous copying of a derived type with a 
deferred-length character array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200

   What|Removed |Added

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

[Bug fortran/89200] [9 Regression] Erroneous copying of a derived type with a deferred-length character array component

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sat Feb  9 11:11:33 2019
New Revision: 268721

URL: https://gcc.gnu.org/viewcvs?rev=268721=gcc=rev
Log:
2019-02-09  Paul Thomas  

PR fortran/89200
* trans-array.c (gfc_trans_create_temp_array): Set the 'span'
field for derived types.

2019-02-09  Paul Thomas  

PR fortran/89200
* gfortran.dg/array_reference_2.f90 : New test.


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

[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> > IMO this PR should be closed as WONTFIX.
>
> Or document it - a single sentence should be enough.

Well the following patch (untested) "fixes" this PR:

--- ../_clean/gcc/fortran/gfortran.h2019-02-02 17:23:28.0 +0100
+++ gcc/fortran/gfortran.h  2019-02-09 11:17:44.0 +0100
@@ -2681,7 +2681,7 @@ typedef struct
   int flag_preprocessed;
   int flag_d_lines;
   int flag_init_integer;
-  int flag_init_integer_value;
+  long int flag_init_integer_value;
   int flag_init_logical;
   int flag_init_character;
   char flag_init_character_value;
@@ -708,7 +708,7 @@ gfc_handle_option (size_t scode, const c

 case OPT_finit_integer_:
   gfc_option.flag_init_integer = GFC_INIT_INTEGER_ON;
-  gfc_option.flag_init_integer_value = atoi (arg);
+  gfc_option.flag_init_integer_value = atol(arg);
   break;

 case OPT_finit_character_:

While playing with the problem I have noticed that if the value in
-finit-integer=N is outside the representable integer, the value is wrapped
around: if N = 128, integer(1) is initialized with -128. IMO this should be
documented.

With the above patch, this is not true for integer(8): if N=Huge(1_8)+1,
integer(8) is initialized with huge(1_8). In addition integer(16) is also
initialized with huge(1_8).

Publish Article and Become Editorial Board Members/Reviewers

[Maydim Malkov]

Dear Scholar/Processor,
We publish open access, peer-reviewed journals which devoted to promoting
the development of science and technology. Now we sincerely invite scholars
and researchers to submit papers to the journals or to join us as one of
the editorial board members/reviewers.
Invitation of Being the Member of the Editorial Board/Reviewer
To expand the editorial board and reviewer team, we would like to invite
you to be our editorial member or reviewer of our journals with great
sincerity. If you are eager for more information about the Benefits and
Responsibilities of the editorial member or a reviewer, please feel free to
visit the following link:
http://www.biochemmolbio.org/journals
Invitation to Submit Your Manuscript
As an international academic publisher, we have more than 200 open access,
online, peer-reviewed journals. If you have burst out some new ideas in
your specialized or interested field, welcome to submit your papers to the
related Journals or Special Issues so that you can share your ideas with
people all over the world.
List of Suggested Journals

   1. Nanoscience and Nanometrology
   2. Humanities and Social Sciences
   3. American Journal of Neural Networks and Applications
   4. Agriculture, Forestry and Fisheries
   5. American Journal of Nursing Science
   6. Hydrology
   7. American Journal of Software Engineering and Applications
   8. Science Journal of Business and Management

We are looking forward to a fruitful cooperation with you.
Thanks and regards,
Jessie Wright

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[iains at gcc dot gnu.org]

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

--- Comment #34 from Iain Sandoe  ---
(In reply to Alan Modra from comment #33)
> It looks to me like that hunk is just removing some dead code, so it doesn't
> matter whether it stays or goes.

yes, just a tidy-up, should not affect function (but maybe best to apply when
it's fresh in the mind).  I can try to talk care of it tomorrow.

[Bug tree-optimization/89263] Simplify bool expression to OR

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-09
 Ever confirmed|0   |1

--- Comment #2 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #1)
> Basically we need to convert a != 0 ? true : b != 0

Actually, just a != 0 ? true : b, the second != 0 isn't there, the first one
exists only because GIMPLE_COND cannot have just a bool argument. Although we
actually see a != 0 ? a : b...

   [local count: 1073741824]:
  if (a_2(D) != 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:

   [local count: 1073741824]:
  # _1 = PHI 

needs to become

  _1 = a_2(D) | b_3(D);

[Bug tree-optimization/89263] Simplify bool expression to OR

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
I thought I have this one filed before but I can't find it.

Basically we need to convert a != 0 ? true : b != 0 into a != 0 | b != 0 which
then will be a | b as != is not needed for boolean types.

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[amodra at gmail dot com]

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

--- Comment #33 from Alan Modra  ---
It looks to me like that hunk is just removing some dead code, so it doesn't
matter whether it stays or goes.

[Bug tree-optimization/89263] New: Simplify bool expression to OR

[david.bolvansky at gmail dot com]

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

Bug ID: 89263
   Summary: Simplify bool expression to OR
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

bool foo(bool a, bool b)
{
if (a)
return true;
return b;   
}

Current:
foo(bool, bool):
testdil, dil
mov eax, esi
cmovne  eax, edi
ret

Better:
foo(bool, bool):
  mov eax, edi
  or eax, esi
  ret

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||vermaelen.wouter at gmail dot 
com

--- Comment #32 from Alexander Monakov  ---
*** Bug 49552 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/49552] missed optimization: test for zero remainder after division by a constant.

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Alexander Monakov  ---
This was implemented for gcc-9 via PR 82853; it seems this bug was overlooked
in the renewed discussion.

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

[Bug target/89261] ix86_data_alignment has wrong argument type

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #0)
> i386.c has
> 
> int
> ix86_data_alignment (tree type, int align, bool opt)
> 
> But "align" passed down is unsigned.

Where is the bug?

I don't think anybody passed negative alignment or alignment >= 2G.

[Bug libbacktrace/89262] New: [libbacktrace] dwarf5 support

[vries at gcc dot gnu.org]

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

Bug ID: 89262
   Summary: [libbacktrace] dwarf5 support
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

build_address_map contains:
...
  version = read_uint16 (_buf);
  if (version < 2 || version > 4)
{
  dwarf_buf_error (_buf, "unrecognized DWARF version");
  goto fail;
}
...

[Bug middle-end/89243] [8 Regression] ICE in new test case g++.dg/opt/pr89188.C from r268647

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/89234] [7 Regression] ICE in get_eh_region_and_lp_from_rtx at gcc/except.c:1824

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
   |get_eh_region_and_lp_from_r |get_eh_region_and_lp_from_r
   |tx at gcc/except.c:1824 |tx at gcc/except.c:1824

--- Comment #9 from Jakub Jelinek  ---
Fixed for 8.3 too.

[Bug rtl-optimization/89234] [7 Regression] ICE in get_eh_region_and_lp_from_rtx at gcc/except.c:1824

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Jakub Jelinek  ---
Not fixed for 7.x yet.

[Bug middle-end/89246] LTO produces references to cloned symbols which the compiler failed to clone

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb  9 08:55:39 2019
New Revision: 268718

URL: https://gcc.gnu.org/viewcvs?rev=268718=gcc=rev
Log:
PR middle-end/89246
* config/i386/i386.c (ix86_simd_clone_compute_vecsize_and_simdlen):
If !node->definition and TYPE_ARG_TYPES is non-NULL, use
TYPE_ARG_TYPES instead of DECL_ARGUMENTS.

* gcc.dg/gomp/pr89246-1.c: New test.
* gcc.dg/gomp/pr89246-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr89246-1.c
trunk/gcc/testsuite/gcc.dg/gomp/pr89246-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88861] [9 Regression] ICE in calc_dfs_tree, at dominance.c:458

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb  9 08:51:41 2019
New Revision: 268717

URL: https://gcc.gnu.org/viewcvs?rev=268717=gcc=rev
Log:
PR middle-end/89243
* g++.dg/opt/pr89188.C: Include ../torture/pr88861.C.

Backported from mainline
2019-01-16  David Malcolm  

PR target/88861
* combine.c (delete_noop_moves): Convert to "bool" return,
returning true if any edges are eliminated.
(combine_instructions): Also return true if delete_noop_moves
returns true.

* g++.dg/torture/pr88861.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr88861.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/combine.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/g++.dg/opt/pr89188.C

[Bug middle-end/89243] [8 Regression] ICE in new test case g++.dg/opt/pr89188.C from r268647

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb  9 08:51:41 2019
New Revision: 268717

URL: https://gcc.gnu.org/viewcvs?rev=268717=gcc=rev
Log:
PR middle-end/89243
* g++.dg/opt/pr89188.C: Include ../torture/pr88861.C.

Backported from mainline
2019-01-16  David Malcolm  

PR target/88861
* combine.c (delete_noop_moves): Convert to "bool" return,
returning true if any edges are eliminated.
(combine_instructions): Also return true if delete_noop_moves
returns true.

* g++.dg/torture/pr88861.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr88861.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/combine.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/g++.dg/opt/pr89188.C

[Bug rtl-optimization/89234] [7/8 Regression] ICE in get_eh_region_and_lp_from_rtx at gcc/except.c:1824

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb  9 08:50:05 2019
New Revision: 268716

URL: https://gcc.gnu.org/viewcvs?rev=268716=gcc=rev
Log:
Backported from mainline
2019-02-08  Jakub Jelinek  

PR rtl-optimization/89234
* except.c (copy_reg_eh_region_note_forward): Return if note_or_insn
is a NOTE, CODE_LABEL etc. - rtx_insn * other than INSN_P.
(copy_reg_eh_region_note_backward): Likewise.

* g++.dg/ubsan/pr89234.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/ubsan/pr89234.C
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/except.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[iains at gcc dot gnu.org]

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

--- Comment #32 from Iain Sandoe  ---
Thanks for the patches Alan.

Note that 7 and 8 back ports might need this hunk which was applied to trunk
but removed from 7 and 8 when we backed out the change because of breakage
there.

@@ -23970,13 +23974,6 @@ first_reg_to_save (void)
 if (save_reg_p (first_reg))
   break;

-#if TARGET_MACHO
-  if (flag_pic
-  && crtl->uses_pic_offset_table
-  && first_reg > RS6000_PIC_OFFSET_TABLE_REGNUM)
-return RS6000_PIC_OFFSET_TABLE_REGNUM;
-#endif
-
   return first_reg;
 }


my ppc darwin box is busy with test cycle at present, but I will check 8.2.1
tomorrow with the patch as applied - and also look to see if the hunk above is
needed?

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[amodra at gcc dot gnu.org]

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

--- Comment #31 from Alan Modra  ---
Author: amodra
Date: Sat Feb  9 08:39:58 2019
New Revision: 268715

URL: https://gcc.gnu.org/viewcvs?rev=268715=gcc=rev
Log:
[RS6000] Correct save_reg_p

PR target/88343
* config/rs6000/rs6000.c (save_reg_p): Match logic in
rs6000_emit_prologue emitting pic_offset_table setup.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000.c

[Bug target/89251] [2018-q4m] Wrong datatype optimization on bitfield

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Kochise from comment #5)
> That the "standard" never really ruled about bitfield order is already
> baffling and common sense (ie. current implementation) telling to start from
> bit 0 and upward is a good thing.

PowerPC bit-field ordering is different than that too.

[Bug target/89251] [2018-q4m] Wrong datatype optimization on bitfield

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Using a smaller than declared size for standard loads is a valid and well
defined optimization (sometimes those use less bandwidth, othertimes it is
better for alignment reasons).  The case you are running into is that you don't
want to use that kind of load.  You should not using bitfields directly and
really should be using volatile here.  Volatile definition is exactly what is
needed for hardware registers and IIRC is the real only working case for
volatile these days (the other working case is a variable that changes due to
an interrupt/signal).