[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
Now it is fixed. It needs both patches.

[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 11 08:02:26 2018
New Revision: 256479

URL: https://gcc.gnu.org/viewcvs?rev=256479&root=gcc&view=rev
Log:
PR middle-end/83575
* cfgrtl.c (rtl_verify_edges): Only verify fixability of partition
when in layout mode.
(cfg_layout_finalize): Do not verify cfg before we are out of layout.
* cfgcleanup.c (try_optimize_cfg): Only verify flow info when doing
partition fixup.

* gcc.c-torture/compile/pr83575.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr83575.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83768] ARM: wrong optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Note GCC 5 is no longer maintained, so if GCC 6+ works this is fixed.

[Bug target/83775] Segfault in arm_declare_function_name()

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #0)
> Hi,
> For the following test-case:
> 
> #define STR "1234567"
> 
> const char str[] = STR;
> 
> char dst[10];
> 
> void copy_from_global_str (void)
> {
>   __builtin_strcpy (dst, str);
> 
>   if (__builtin_strlen (dst) != sizeof str - 1)
> __builtin_abort ();
> }
> 
> With arm-linux-gnueabihf-gcc -O2 I get the following ICE:
Oops, this should be cc1, I didn't invoke the driver, but cc1 directly.

> strlenopt-39.c: In function 'copy_from_global_str':
> strlenopt-39.c:13:1: internal compiler error: Segmentation fault
>  }
>  ^
> 0xbc1f1f crash_signal
>   ../../gcc/gcc/toplev.c:325
> 0xf4a5bb std::char_traits::length(char const*)
>   /usr/include/c++/6/bits/char_traits.h:267
> 0xf4a5bb std::__cxx11::basic_string,
> std::allocator >::assign(char const*)
>   /usr/include/c++/6/bits/basic_string.h:1268
> 0xf4a5bb std::__cxx11::basic_string,
> std::allocator >::operator=(char const*)
>   /usr/include/c++/6/bits/basic_string.h:605
> 0xf4a5bb arm_declare_function_name(_IO_FILE*, char const*, tree_node*)
>   ../../gcc/gcc/config/arm/arm.c:30958
> 0xf4ad2d arm_asm_declare_function_name(_IO_FILE*, char const*, tree_node*)
>   ../../gcc/gcc/config/arm/arm.c:19899
> 0xefd8fc assemble_start_function(tree_node*, char const*)
>   ../../gcc/gcc/varasm.c:1880
> 0x87929f rest_of_handle_final
>   ../../gcc/gcc/final.c:4549
> 0x87929f execute
>   ../../gcc/gcc/final.c:4625
> 
> This happens because of following in arm_declare_function_name():
>   /* Only update the assembler .arch string if it is distinct from the last
>  such string we printed.  */
>   std::string arch_to_print = targ_options->x_arm_arch_string;
> 
> In this case, targ_options->x_arm_arch_string is NULL and hence the above
> error.
> Does the following (untested) fix look OK ?
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 196aa6de1ac..868251a154c 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -30954,7 +30954,10 @@ arm_declare_function_name (FILE *stream, const char
> *name, tree decl)
> 
>/* Only update the assembler .arch string if it is distinct from the last
>   such string we printed.  */
> -  std::string arch_to_print = targ_options->x_arm_arch_string;
> +  std::string arch_to_print;
> +  if (targ_options->x_arm_arch_string)
> +arch_to_print = targ_options->x_arm_arch_string;
> +
>if (arch_to_print != arm_last_printed_arch_string)
>  {
>std::string arch_name
> 
> 
> Thanks,
> Prathamesh

[Bug rtl-optimization/83770] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/83771] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 3 reachable only by paths crossing the cold partition)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/83772] [8 Regression] ICE in new test case gfortran.fortran-torture/compile/pr83081.f90 in r256423

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|testsuite   |middle-end
   Target Milestone|--- |8.0
Summary|ICE in new test case|[8 Regression] ICE in new
   |gfortran.fortran-torture/co |test case
   |mpile/pr83081.f90 in|gfortran.fortran-torture/co
   |r256423 |mpile/pr83081.f90 in
   ||r256423

[Bug target/83775] Segfault in arm_declare_function_name()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Dup then.

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

[Bug tree-optimization/83189] [8 regression] internal compiler error: in probability_in, at profile-count.h:1050

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 11 08:14:33 2018
New Revision: 256480

URL: https://gcc.gnu.org/viewcvs?rev=256480&root=gcc&view=rev
Log:

PR middle-end/83189
* gfortran.fortran-torture/compile/pr83189.f90: New testcase.
* tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Handle zero
profile.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83189.f90
  - copied unchanged from r256479,
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90
Removed:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-manip.c

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
*** Bug 83775 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
   Target Milestone|--- |6.5
Summary|[5/6/7/8 Regression]|[6/7/8 Regression] missing
   |missing -Warray-bounds  |-Warray-bounds indexing
   |indexing past the end of a  |past the end of a string
   |string literal  |literal
 Ever confirmed|0   |1

[Bug tree-optimization/83774] ICE at -O3 with -Wall: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |8.0
 Resolution|--- |FIXED

--- Comment #1 from Richard Biener  ---
Confirmed and confirmed fixed after updating my tree.

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #13)
> Does the kernel still need this workaround?  Shall we just add the option
> and gradually add the checks?

Yes - note I got stuck in the attempt to do the -f[no-]strict-overflow aliasing
in common.opt in a way to also cover this new option and then forgot about it.
Appearantly we can't have two Aliases nor does EnabledBy work here :/

Also note my remark on not re-introducing POINTER_OVERFLOW_UNDEFINED but
instead allowing TYPE_OVERFLOW_* on pointers.

Want to give it a try?

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[sebastian.hu...@embedded-brains.de]

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

--- Comment #3 from Sebastian Huber  ---
Created attachment 43096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43096&action=edit
Test case.

/home/sh/b-gcc-bfin/./gcc/xgcc -B/home/sh/b-gcc-bfin/./gcc/ -c sum_c8.i -O2 -g

[Bug target/83785] New: sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344

[sebastian.hu...@embedded-brains.de]

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

Bug ID: 83785
   Summary: sh: ICE in maybe_record_trace_start, at
dwarf2cfi.c:2344
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Created attachment 43097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43097&action=edit
Test case.

/home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -c matmul_i8.i -O2 -g
-funroll-loops --param max-unroll-times=4
during RTL pass: dwarf2
/home/sh/src/gcc/libgfortran/generated/matmul_i8.c: In function 'matmul_i8':
/home/sh/src/gcc/libgfortran/generated/matmul_i8.c:2922:1: internal compiler
error: in maybe_record_trace_start, at dwarf2cfi.c:2344
 }
 ^
0x102bef2f maybe_record_trace_start
/home/sh/src/gcc/gcc/dwarf2cfi.c:2344
0x102bf587 create_trace_edges
/home/sh/src/gcc/gcc/dwarf2cfi.c:2440
0x102c40b7 scan_trace
/home/sh/src/gcc/gcc/dwarf2cfi.c:2653
0x102c4c77 create_cfi_notes
/home/sh/src/gcc/gcc/dwarf2cfi.c:2679
0x102c4c77 execute_dwarf2_frame
/home/sh/src/gcc/gcc/dwarf2cfi.c:3037
0x102c4c77 execute
/home/sh/src/gcc/gcc/dwarf2cfi.c:3525
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 11 Jan 2018, matthew at wil dot cx wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653
> 
> --- Comment #5 from Matthew Wilcox  ---
> Hi Aldy!
> 
> Thanks for looking into this.  Yes, I agree, there's no way that GCC can know
> this is a constant, but that *should* have been taken care of.  Please pardon
> me copying and pasting from the original source file rather than the
> preprocessed source, but I find it utterly impossible to work with the
> preprocessed source ...
> 
> #define atomic_sub_return(i,v)  \
> ({  \
> int __ia64_asr_i = (i); \
> (__builtin_constant_p(i)\
>  && (   (__ia64_asr_i ==   1) || (__ia64_asr_i ==   4)  \
>  || (__ia64_asr_i ==   8) || (__ia64_asr_i ==  16)  \
>  || (__ia64_asr_i ==  -1) || (__ia64_asr_i ==  -4)  \
>  || (__ia64_asr_i ==  -8) || (__ia64_asr_i == -16)))\
> ? ia64_fetch_and_add(-__ia64_asr_i, &(v)->counter)  \
> : ia64_atomic_sub(__ia64_asr_i, v); \
> })
> 
> That __builtin_constant_p() *should* have led GCC to throw up its hands, not
> bother checking for the +/- 1, 4, 8, 16 cases and just call 
> ia64_atomic_sub(). 
> Looking at the disassembly, I see a BBB bundle, indicating quite strongly to 
> me
> that it is testing for all of these cases, and the __builtin_constant_p is
> being ... ignored?  misunderstood?

The usual events are that we perform some jump threading across
the __builtin_constant_p before it is resolved, exposing the constant
path somewhere 'i' isn't constant.

The builtin really doesn't guarantee what kernel folks want, because
at one point they want it resolved very late so optimization can
eventually figure out 'i' _is_ constant on the other hand some
optimizations might pull out stuff across it and break expectations.

Note I didn't try to figure what exactly goes wrong but I believe
we had duplicate issues (also in the kernel) that were worked
around in the source by just removing the stupid optimization
and relying on GCC to perform it for constant 'i'.

[Bug c++/83777] Invalid dependent initialization of a static data member.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-11
Version|unknown |7.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Are you sure?  It looks like C::type doesn't instantiate C
because it isn't dependent?

clang accepts the testcase without error as well.

[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c++/83779] Trivial bounds error not detected with -fbounds-check

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Should have been a FE-only option I guess.

[Bug sanitizer/83780] False positive alignment error with -fsanitize=undefined with virtual base

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Jason/Nathan, is the TYPE_ALIGN right here?

[Bug tree-optimization/83784] Missed optimization with bitfield

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I guess it would need "load merging" as opposed to store merging,
basically what the bswap pass does but for bitfields.  I've always said those
two passes need to be merged somehow ;)

Anyway, bswap analysis is byte-granular currently and its lattice data
structure
would have to be beefed up quite considerably (also making operations on it
more costly).

bitfield lowering would have fixes this bug as well I guess (lowering
accesses to use the bitfield representative).

There are a few related bugs.

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
With that change, we end up with weird array, TYPE_SIZE_UNIT/TYPE_SIZE on its
type is constant, but DECL_SIZE_UNIT/DECL_SIZE on the decl is non-constant
(pedantically it is a VLA, but we know the sizes at compile time).
So, gimplify_vla_decl is invoked on it.  Perhaps just omp-low.c
(is_variable_sized) should be changed:
 static inline bool
 is_variable_sized (const_tree expr)
 {
+  if (DECL_P (expr))
+return TREE_CODE (DECL_SIZE_UNIT (expr)) != INTEGER_CST;
   return !TREE_CONSTANT (TYPE_SIZE_UNIT (TREE_TYPE (expr)));
 }   

I don't have nvptx offloading setup yet on my WS after reinstalling it, can you
check if following works with -fopenmp -O2 or not?

const int n = 100;

int
main ()
{
  int s = 0;
  int array[n];

  for (int i = 0; i < n; i++)
array[i] = i + 1;

#pragma omp target parallel for map(tofrom:s) reduction (+:s)
  for (int i = 0; i < n; i++)
s += array[i];

#pragma omp target parallel for map(tofrom:s) reduction (+:s) map(to:array)
  for (int i = 0; i < n; i++)
s += array[i];

  if (s != n * (n + 1))
__builtin_abort ();

  return 0;
}

[Bug tree-optimization/83784] Missed optimization with bitfield

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I'm afraid the bswap pass infrastructure is really unusable here, extending it
so that it handles bit twiddling would be too expensive.

[Bug other/83786] New: Add VEC_ORDERED_REMOVE_IF

[vries at gcc dot gnu.org]

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

Bug ID: 83786
   Summary: Add VEC_ORDERED_REMOVE_IF
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There's a common pattern of using vec::ordered_remove in a loop to remove some
elements, which has  O(n^2) complexity.

I've written a patch that adds the macro VEC_ORDERED_REMOVE_IF which can be
used in such a case to achieve the same, but with O(n) complexity.

[Bug other/83786] Add VEC_ORDERED_REMOVE_IF

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Tom de Vries  ---
Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00338.html
.

I'm filing a bug for this to make sure it doesn't fall through the cracks (give
that we're at the end of stage 3, and this may be more of a stage1 thing, I'm
not sure).

[Bug middle-end/83772] [8 Regression] ICE in new test case gfortran.fortran-torture/compile/pr83081.f90 in r256423

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
Seen on arm and aarch64 too.

[Bug middle-end/83772] [8 Regression] ICE in new test case gfortran.fortran-torture/compile/pr83081.f90 in r256423

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
The test has been removed at revision r256480:

Dgcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90

Closing.

[Bug tree-optimization/83435] [8 Regression] ICE in set_value_range, at tree-vrp.c:211

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
I have a patch robustifying VRP.  Yes, we don't want to leak overflow constants
into the IL but we're not there yet and I'd rather have this done in a robust
way but couldn't yet thing of one (like not creating them in the first place
when
in GIMPLE form?!  But we have to audit our codebase on where TREE_OVERFLOW is
expected to be set - IIRC that's mostly FEs, but only "mostly"...).

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43098&action=edit
gcc8-pr83590.patch

Actually, the problem is much more severe.  The thing is, neither the
TYPE_SIZE_UNIT nor DECL_SIZE_UNIT is INTEGER_CST from the FE, it becomes
INTEGER_CST when gimplify_one_sizepos is called on these.  First we gimplify
the TYPE_SIZE*, then check DECL_SIZE* for not being INTEGER_CST and then we
gimplify DECL_SIZE*, at which point it becomes also INTEGER_CST.  But we are
already determined to treat it as VLA and create DECL_VALUE_EXPR for it.  Of
course all the OpenMP/OpenACC lowering/expansion code checks for special
treatment of VLA by checking either DECL_SIZE* or TYPE_SIZE* or
variably_modified*, but none of these are true.  So, either we can do what this
patch does, or we'd need to introduce some flag whether gimplify_vla_decl has
been done on it (parsing DECL_VALUE_EXPR and trying to understand if it is due
to being VLA or myriads of other reasons why it has DECL_VALUE_EXPR is too
hard).

Can you give this a spin?

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
I can confirm that the problem still exists on GCC 7 branch and probably also
on trunk (trunk does not build the app because of another bug).  The patch
above fixes the problem and the app runs.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #56 from rguenther at suse dot de  ---
> On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
[...]
> I can reproduce that with -ffat-lto-objects where indeed we somehow
> get confused when we should preserve only part of a SHT_GROUP given
> we don't "prune" groups.  The question to me is why do we put
> both macro sections in a single group ...  but that's probably
> an artifact on how things are supposed to work in the end...
> [I wonder if SHF_EXCLUDE works "properly" for group members when
> doing a non-LTO link]
>
> Anyway, this should be "easy" to fix with sth like
>
>   else if (sh_type == SHT_GROUP)
> {
>   /* Remap section indices in groups and remove removed members.  
> */
>   unsigned char *ent, *dst;
>   for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4)
> {
>   unsigned shndx = type_functions->fetch_Elf_Word (ent);
>   if (pfnret[shndx - 1] == -1)
> ;
>   else
> {
>   type_functions->set_Elf_Word (dst, sh_map[shndx]);
>   dst += 4;
> }
> }
>   /* Adjust the length.  */
>   length = dst - buf;
> }
>
> in the group handling.
>
> That fixes -ffat-lto-objects handling for me with the testcase.
> Will re-test with that.

[I'm continuing this with examples from a build using gas 2.29 instead
of as since things are easier to see there.]

While this fixed the error in the group section

Group Section:  .group
  Signature Symbol: wm4.0.b58ba986a79b71e96526231091292919
  Members:
index   flags / section
  [0]   [ COMDAT ]
  [1]   .debug_macro

COMDAT group section [1] `.group' [wm4.0.b58ba986a79b71e96526231091292919]
contains 1 sections:
   [Index]Name
   [7]   .debug_macro

the link error (during ld -r) remains:

ld: fatal: relocation error: R_386_32: file /var/tmp//cco6lLmcdebugobjtem:
section [6].rel.debug_macro: symbol .debug_macro (section): symbol has been
discarded with discarded section: [7].debug_macro

Relocation Section:  .rel.debug_macro
  index  type  offset value  section  symbol
[0]  R_386_32 0x3 0  .debug_macro .debug_line (section)
[1]  R_386_32 0x8 0  .debug_macro .debug_macro (section)

We do have two .debug_macro sections and their corresponding reloc
sections here, as already in the input objects:

Section Header[6]:  sh_name: .rel.debug_macro
sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
sh_size:  0x10sh_type:[ SHT_REL ]
sh_offset:0x324   sh_entsize: 0x8 (2 entries)
sh_link:  11  sh_info:5
sh_addralign: 0x4   

Section Header[8]:  sh_name: .rel.debug_macro
sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
sh_size:  0xa50   sh_type:[ SHT_REL ]
sh_offset:0xaf4   sh_entsize: 0x8 (330 entries)
sh_link:  11  sh_info:7
sh_addralign: 0x4   

Section Header[5]:  sh_name: .debug_macro
sh_addr:  0   sh_flags:   0
sh_size:  0x11sh_type:[ SHT_PROGBITS ]
sh_offset:0x312   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

Section Header[7]:  sh_name: .debug_macro
sh_addr:  0   sh_flags:   [ SHF_GROUP ]
sh_size:  0x7c0   sh_type:[ SHT_PROGBITS ]
sh_offset:0x334   sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x1   

Rainer

[Bug go/83787] New: [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL after Go1.10beta1 update

[ro at gcc dot gnu.org]

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

Bug ID: 83787
   Summary: [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL
after Go1.10beta1 update
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
  Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
 Build: sparc-sun-solaris2.*

Even after the Go1.10beta1 update and the __go_construct_map fix, many 32-bit
tests (both in go.test, go.go-torture and libgo) FAIL on 32-bit Solaris/SPARC:

FAIL: go.go-torture/execute/chan-1.go execution,  -O0 
FAIL: go.go-torture/execute/chan-1.go execution,  -O1 
FAIL: go.go-torture/execute/chan-1.go execution,  -O2 
FAIL: go.go-torture/execute/chan-1.go execution,  -O2 -fbounds-check 
FAIL: go.go-torture/execute/chan-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions 
FAIL: go.go-torture/execute/chan-1.go execution,  -O2 -fomit-frame-pointer
-finline-functions -funroll-loops 
FAIL: go.go-torture/execute/chan-1.go execution,  -O3 -g 
FAIL: go.go-torture/execute/chan-1.go execution,  -Os 
FAIL: ./index0-out.go execution,  -O0 -g -fno-var-tracking-assignments 
FAIL: ./select5-out.go execution,  -O0 -g -fno-var-tracking-assignments 
FAIL: go.test/test/235.go execution,  -O2 -g 
FAIL: go.test/test/chan/fifo.go execution,  -O2 -g 
FAIL: go.test/test/chan/nonblock.go execution,  -O2 -g 
FAIL: go.test/test/chan/select.go execution,  -O2 -g 
FAIL: go.test/test/chan/select3.go execution,  -O2 -g 
FAIL: go.test/test/chan/select4.go execution,  -O2 -g 
FAIL: go.test/test/chan/sendstmt.go execution,  -O2 -g 
FAIL: go.test/test/chan/sieve2.go execution,  -O2 -g 
FAIL: go.test/test/chancap.go execution,  -O2 -g 
FAIL: go.test/test/closedchan.go execution,  -O2 -g 
FAIL: go.test/test/const4.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug225.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug230.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug234.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug242.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug273.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug312.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/bug320.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/issue4313.go execution,  -O2 -g 
FAIL: go.test/test/fixedbugs/issue4562.go execution,  -O2 -g 
FAIL: go.test/test/nil.go execution,  -O2 -g 
WARNING: program timed out.

FAIL: io
FAIL: net
FAIL: reflect
FAIL: runtime
FAIL: sync
FAIL: time
FAIL: cmd/internal/buildid
FAIL: database/sql
FAIL: encoding/base64
FAIL: go/build
FAIL: internal/singleflight
FAIL: log/syslog
FAIL: net/http
FAIL: net/http/cgi
FAIL: net/http/httptest
FAIL: net/http/httputil
FAIL: net/rpc
FAIL: net/rpc/jsonrpc
FAIL: os/signal
FAIL: runtime/pprof

Quite a number of them (like go.go-torture/execute/chan-1.go) are like
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main
   
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/chan-1.go:5

but there are several others:

Send returned 0 != 2
panic: fail

goroutine 1 [running]:
panic
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:554
main.main
   
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.test/test/chan/select.go:52
FAIL: go.test/test/chan/select.go execution,  -O2 -g 

panic: function did block

goroutine 1 [running]:
panic
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:554
main.testBlock
   
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.test/test/chan/select3.go:50
main.main
   
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.test/test/chan/select3.go:86
FAIL: go.test/test/chan/select3.go execution,  -O2 -g 

chan len/cap  0 0  want 0 10
panic: fail

goroutine 1 [running]:
panic
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:554
main.main
/vol/gcc/src/hg/trunk/local/gcc/testsuite/go.test/test/chancap.go:15
FAIL: go.test/test/chancap.go execution,  -O2 -g 

SIGABRT: abort
PC=0 m=0 sigcode=18446744073709551615

goroutine 1 [running]:

FAIL: go.test/test/nil.go execution,  -O2 -g 

Besides at least 4 different gotools tests hang indefinitely and had to be
killed manually to allow the build to finish.

  Rainer

[Bug go/83787] [8 regression] Many 32-bit Solaris/SPARC Go tests FAIL after Go1.10beta1 update

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Jan 11 09:54:26 2018
New Revision: 256525

URL: https://gcc.gnu.org/viewcvs?rev=256525&root=gcc&view=rev
Log:
Fix mode_for_size units in caller-save.c (PR83761)

The new opt_mode asserts triggered for replace_reg_with_saved_mem
because it was passing bytes rather than bits to mode_for_size.
Previously we ended up with a BLKmode register instead, but
presumably that didn't matter because this is "only" used for
debug insns.

2018-01-11  Richard Sandiford  

gcc/
PR rtl-optimization/83761
* caller-save.c (replace_reg_with_saved_mem): Pass bits rather
than bytes to mode_for_size.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/caller-save.c

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 43098 [details]
> gcc8-pr83590.patch

> Can you give this a spin?

Will do.

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Thanks, patch applied.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenther at suse dot de]

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

--- Comment #58 from rguenther at suse dot de  ---
On Thu, 11 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
> 
> --- Comment #57 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #56 from rguenther at suse dot de  ---
> > On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> [...]
> > I can reproduce that with -ffat-lto-objects where indeed we somehow
> > get confused when we should preserve only part of a SHT_GROUP given
> > we don't "prune" groups.  The question to me is why do we put
> > both macro sections in a single group ...  but that's probably
> > an artifact on how things are supposed to work in the end...
> > [I wonder if SHF_EXCLUDE works "properly" for group members when
> > doing a non-LTO link]
> >
> > Anyway, this should be "easy" to fix with sth like
> >
> >   else if (sh_type == SHT_GROUP)
> > {
> >   /* Remap section indices in groups and remove removed members.  
> > */
> >   unsigned char *ent, *dst;
> >   for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4)

^^^ typo here, should be ent < buf + length

> > {
> >   unsigned shndx = type_functions->fetch_Elf_Word (ent);
> >   if (pfnret[shndx - 1] == -1)
> > ;
> >   else
> > {
> >   type_functions->set_Elf_Word (dst, sh_map[shndx]);
> >   dst += 4;
> > }
> > }
> >   /* Adjust the length.  */
> >   length = dst - buf;
> > }
> >
> > in the group handling.
> >
> > That fixes -ffat-lto-objects handling for me with the testcase.
> > Will re-test with that.
> 
> [I'm continuing this with examples from a build using gas 2.29 instead
> of as since things are easier to see there.]
> 
> While this fixed the error in the group section
> 
> Group Section:  .group
>   Signature Symbol: wm4.0.b58ba986a79b71e96526231091292919
>   Members:
> index   flags / section
>   [0]   [ COMDAT ]
>   [1]   .debug_macro
> 
> COMDAT group section [1] `.group' [wm4.0.b58ba986a79b71e96526231091292919]
> contains 1 sections:
>[Index]Name
>[7]   .debug_macro
> 
> the link error (during ld -r) remains:

From Solaris ld?  In both sources to the testcase I only have one
COMDAT group -- the above indicates there are two?  In elf.h I see
there's a SHT_SUNW_COMDAT - is that used?  That would mean we have to
remap sections not only in SHT_GROUP but also SHT_SUNW_COMDAT?  Also
web docs suggest that SUN ld might discard one of the two sections
because it identifies them by name?  This would mean it breaks whatever
intent we had in producing two .debug_macro (even w/o LTO)?  As said,
on x86_64 linux I have only one comdat .debug_macro section and the
other .debug_macro section refers to that via a reloc entry.

So what's the behavior without -flto here if you do a partial link
of the two input objects?

> ld: fatal: relocation error: R_386_32: file /var/tmp//cco6lLmcdebugobjtem:
> section [6].rel.debug_macro: symbol .debug_macro (section): symbol has been
> discarded with discarded section: [7].debug_macro
> 
> Relocation Section:  .rel.debug_macro
>   index  type  offset value  section  symbol
> [0]  R_386_32 0x3 0  .debug_macro .debug_line (section)
> [1]  R_386_32 0x8 0  .debug_macro .debug_macro (section)
>
> We do have two .debug_macro sections and their corresponding reloc
> sections here, as already in the input objects:
> 
> Section Header[6]:  sh_name: .rel.debug_macro
> sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
> sh_size:  0x10sh_type:[ SHT_REL ]
> sh_offset:0x324   sh_entsize: 0x8 (2 entries)
> sh_link:  11  sh_info:5
> sh_addralign: 0x4   
> 
> Section Header[8]:  sh_name: .rel.debug_macro
> sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
> sh_size:  0xa50   sh_type:[ SHT_REL ]
> sh_offset:0xaf4   sh_entsize: 0x8 (330 entries)
> sh_link:  11  sh_info:7
> sh_addralign: 0x4   
> 
> Section Header[5]:  sh_name: .debug_macro
> sh_addr:  0   sh_flags:   0
> sh_size:  0x11sh_type:[ SHT_PROGBITS ]
> sh_offset:0x312   sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1   
> 
> Section Header[7]:  sh_name: .debug_macro
> sh_addr:  0   sh_flags:   [ SHF_GROUP ]
> sh_size:  0x7c0   sh_type:[ SHT_PROGBITS ]
> sh_offset:0x334   sh_entsize: 0
> sh_link:  0   sh_info:0
> sh_addralign: 0x1   

Yes, and we preserve both.  I'm not 100% sure what the ld error is about?

I do wonder why we have two .debug_macro s

[Bug sanitizer/83780] False positive alignment error with -fsanitize=undefined with virtual base

[securesneakers at gmail dot com]

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

--- Comment #2 from Ivan Bodrov  ---
I have reported the same bug for Clang:
https://bugs.llvm.org/show_bug.cgi?id=35902

Unlike GCC, Clang is also eager to generate unaligned "movaps" instructions,
crashing the program. Afaik GCC does not generate SSE instructions that often,
but I wonder if it can do something similar.

Clang's unaligned movaps bug: https://bugs.llvm.org/show_bug.cgi?id=35901

[Bug debug/83788] New: Add .loc is_stmt support test

[vries at gcc dot gnu.org]

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

Bug ID: 83788
   Summary: Add .loc is_stmt support test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01631.html :
...
Now, perhaps it would be wise to introduce a test for is_stmt support in
.loc directives, now that we know there are assemblers that don't
support it.
...

[Bug debug/83788] Add .loc is_stmt support test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I guess it depends on how exactly it would look like.
Because if the test is simply short asm snippet with .loc directive in it, it
would fail on nvptx anyway, not because .loc with is_stmt is not recognized,
but because the assembly doesn't start with the required directives.
And, if it does contain the required directives specially for nvptx, then it
would on the other side succeed when building nvptx without the cuda headers
and executables, where ptxas can't be invoked and as just does just the most
trivial verification.

[Bug c/83789] New: __builtin_altivec_lvx fails for powerpc for altivec-4.c

[kaushik.phatak at kpitcummins dot com]

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

Bug ID: 83789
   Summary: __builtin_altivec_lvx fails for powerpc for
altivec-4.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaushik.phatak at kpitcummins dot com
  Target Milestone: ---

Regression testcase gcc.target/powerpc/altivec-4.c fails for powerpc gcc-7
onwards.

$powerpc-linux-gcc -m32 -mhard-float -maltivec altivec-4.c -c
min.c: In function 'b':
min.c:16:7: internal compiler error: Segmentation fault
   i = __builtin_altivec_lvx (int1, pi);
   ^~~~
0x85d8690 crash_signal
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/toplev.c:337
0x832f525 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/expr.c:5575
0x8330c91 expand_assignment(tree_node*, tree_node*, bool)
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/expr.c:5321
0x823bb98 expand_call_stmt
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/cfgexpand.c:2656
0x823bb98 expand_gimple_stmt_1
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/cfgexpand.c:3571
0x823bb98 expand_gimple_stmt
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/cfgexpand.c:3737
0x823cbd0 expand_gimple_basic_block
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/cfgexpand.c:5744
0x8241e36 execute
   
/home/kaushikp/toolchain/powerpc/linux_build_71/../src/gcc-7.1.0/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions

The builtin generates the 'CODE_FOR_altivec_lvx_v4si_2op' instruction which 
returns CODE_FOR_nothing resulting in Segmentation fault.
The pattern 'CODE_FOR_altivec_lvx_v4si_2op' was introduced by the following
patch I believe,
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01110.html

The pattern tests for TARGET_64BIT and the testcase passes for powerpc64,
however fails for 32-bit targets. This passed in GCC-6 and earlier branches.

Should we modify the testcase so it runs only for 64-bit targets, 
or should this builtin work for 32-bit targets as well?

[Bug target/83790] New: Update nvptx target to work with cuda 9

[vries at gcc dot gnu.org]

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

Bug ID: 83790
   Summary: Update nvptx target to work with cuda 9
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

One issue is mentioned here:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01318.html . There's a patch, but
testing status is unclear.

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #59 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #58 from rguenther at suse dot de  ---
> On Thu, 11 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
[...]
>> [I'm continuing this with examples from a build using gas 2.29 instead
>> of as since things are easier to see there.]
>> 
>> While this fixed the error in the group section
>> 
>> Group Section:  .group
>>   Signature Symbol: wm4.0.b58ba986a79b71e96526231091292919
>>   Members:
>> index   flags / section
>>   [0]   [ COMDAT ]
>>   [1]   .debug_macro
>> 
>> COMDAT group section [1] `.group' 
>> [wm4.0.b58ba986a79b71e96526231091292919]
>> contains 1 sections:
>>[Index]Name
>>[7]   .debug_macro
>> 
>> the link error (during ld -r) remains:
>
> From Solaris ld?  In both sources to the testcase I only have one

Right: that's the only one I'm regularly testing with.

> COMDAT group -- the above indicates there are two?  In elf.h I see

Oh, sorry, that's just the output of elfdump -g (which showed the
invalid section references before) and readelf -g (which shows the
actual section indices).

> there's a SHT_SUNW_COMDAT - is that used?  That would mean we have to
> remap sections not only in SHT_GROUP but also SHT_SUNW_COMDAT?  Also

Not in the examples I've seen, neither with as nor (expected) with gas.

> web docs suggest that SUN ld might discard one of the two sections
> because it identifies them by name?  This would mean it breaks whatever
> intent we had in producing two .debug_macro (even w/o LTO)?  As said,
> on x86_64 linux I have only one comdat .debug_macro section and the
> other .debug_macro section refers to that via a reloc entry.
>
> So what's the behavior without -flto here if you do a partial link
> of the two input objects?

That works just fine.

>> ld: fatal: relocation error: R_386_32: file /var/tmp//cco6lLmcdebugobjtem:
>> section [6].rel.debug_macro: symbol .debug_macro (section): symbol has been
>> discarded with discarded section: [7].debug_macro
>> 
>> Relocation Section:  .rel.debug_macro
>>   index  type  offset value  section  symbol
>> [0]  R_386_32 0x3 0  .debug_macro .debug_line (section)
>> [1]  R_386_32 0x8 0  .debug_macro .debug_macro (section)
>>
>> We do have two .debug_macro sections and their corresponding reloc
>> sections here, as already in the input objects:
>> 
>> Section Header[6]:  sh_name: .rel.debug_macro
>> sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
>> sh_size:  0x10sh_type:[ SHT_REL ]
>> sh_offset:0x324   sh_entsize: 0x8 (2 entries)
>> sh_link:  11  sh_info:5
>> sh_addralign: 0x4   
>> 
>> Section Header[8]:  sh_name: .rel.debug_macro
>> sh_addr:  0   sh_flags:   [ SHF_INFO_LINK ]
>> sh_size:  0xa50   sh_type:[ SHT_REL ]
>> sh_offset:0xaf4   sh_entsize: 0x8 (330 entries)
>> sh_link:  11  sh_info:7
>> sh_addralign: 0x4   
>> 
>> Section Header[5]:  sh_name: .debug_macro
>> sh_addr:  0   sh_flags:   0
>> sh_size:  0x11sh_type:[ SHT_PROGBITS ]
>> sh_offset:0x312   sh_entsize: 0
>> sh_link:  0   sh_info:0
>> sh_addralign: 0x1   
>> 
>> Section Header[7]:  sh_name: .debug_macro
>> sh_addr:  0   sh_flags:   [ SHF_GROUP ]
>> sh_size:  0x7c0   sh_type:[ SHT_PROGBITS ]
>> sh_offset:0x334   sh_entsize: 0
>> sh_link:  0   sh_info:0
>> sh_addralign: 0x1   
>
> Yes, and we preserve both.  I'm not 100% sure what the ld error is about?

Neither am I.  It's probably best to drag the Solaris linker engineers
in to make progress here.

> I do wonder why we have two .debug_macro sections in the first place
> but I haven't investigated if that's on purpose.  At least we have the
> same without -flto.

Rainer

[Bug testsuite/83791] New: Move tests to libgomp.c-c++-common

[vries at gcc dot gnu.org]

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

Bug ID: 83791
   Summary: Move tests to libgomp.c-c++-common
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The directory libgomp/testsuite/libgomp.c-c++-common was added recently.

There are tests in libgomp/testsuite/libgomp.c that are reused in
libgomp/testsuite/libgomp.c++ using an include, and it makes sense to unify
these two tests by moving themm to libgomp/testsuite/libgomp.c-c++-common.

[Bug testsuite/83791] Move tests to libgomp.c-c++-common

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openmp, patch

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01003.html

[Bug libgomp/83792] New: [openacc] Factor out async argument utility functions

[vries at gcc dot gnu.org]

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

Bug ID: 83792
   Summary: [openacc] Factor out async argument utility functions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The use of enum acc_async_t in libgomp is hard to understand.

In order to understand what this means:
...
if (async < acc_async_noval)
...
you need to know the names and values of the enum.

Using factored out functions, we get something that is easier to understand:
...
if (async_synchronous_p (async))
...

[Bug libgomp/83792] [openacc] Factor out async argument utility functions

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openacc, patch
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01466.html

[Bug c++/83793] New: Pack expansion outside of lambda containing the pack incorrectly rejected

[kretz at kde dot org]

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

Bug ID: 83793
   Summary: Pack expansion outside of lambda containing the pack
incorrectly rejected
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Testcase (https://godbolt.org/g/mNhetZ):

#include 
#include 

using std::size_t;
template  auto f(std::index_sequence) {
std::array x = {[&]() -> int { return Indexes;
}()...};
return x;
}

auto g() {
return f(std::make_index_sequence<3>());
}

The pack expansion of `[&]() -> int { return Indexes; }()` is apparently never
considered. ICC, clang, and MSVC accept the code.

[Bug libgomp/83795] New: Call atexit (gomp_target_fini) before calling target plugin

[vries at gcc dot gnu.org]

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

Bug ID: 83795
   Summary: Call atexit (gomp_target_fini) before calling target
plugin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Registering gomp_target_fini for execution at exit before calling a plugin
function, makes sure that happens before a plugin calls atexit. That way, the
functions registered by a plugin will be executed before gomp_target_fini. 
This gives those functions the possibility to implement cleanups that require
locking and unlocking devices[*].lock.  These cleanups cannot happen during
fini_device_func because:
- gomp_target_fini locks devices[*].lock while calling fini_device_func, and
- the lock is not recursive.

[Bug go/83794] New: misc/cgo/test uses gigabytes of memory

[rguenth at gcc dot gnu.org]

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

Bug ID: 83794
   Summary: misc/cgo/test uses gigabytes of memory
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rguenth at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

Constantly gets my testing machines into swapping.  A big enough machine
reports

5916 rguenth+  20   0 23.376g 0.021t  26476 S 100.00 69.22 6:42.69 test.te

so it's not only big but also very slow.  The failure reporting is also not
very fine-grained it seems given misc/cgo/test is just a directory full of
tests...

PLEASE fix (going to not bootstrap/test with GO for the moment).

[Bug libgomp/83795] Call atexit (gomp_target_fini) before calling target plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01444.html

[Bug target/82096] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[sudi at gcc dot gnu.org]

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

--- Comment #7 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Thu Jan 11 10:46:59 2018
New Revision: 256526

URL: https://gcc.gnu.org/viewcvs?rev=256526&root=gcc&view=rev
Log:
[PR82096] Fix ICE in int_mode_for_mode with arm-linux-gnueabi

The bug reported a particular test di-longlong64-sync-1.c failing when run
on arm-linux-gnueabi with options -mthumb -march=armv5t -O[g,1,2,3] and
-mthumb -march=armv6 -O[g,1,2,3].

The crash was caused because of the explicit VOIDmode argument that is sent
to emit_store_flag_force () and that the emit_store_flag_force () was not
handling the VOIDmode adequately. This patch fixes that.

ChangeLog entries:

*** gcc/ChangeLog ***

2017-01-11  Sudakshina Das  

PR target/82096
* expmed.c (emit_store_flag_force): Swap if const op0
and change VOIDmode to mode of op0.

*** gcc/testsuite/ChangeLog ***

2017-01-11  Sudakshina Das  

PR target/82096
* gcc.c-torture/compile/pr82096.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82096.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog

[Bug go/83794] misc/cgo/test uses gigabytes of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Looks like no useful logs are there btw, I killed the process and all I got (in
gotools/cgo-testlog!?) is

cd cgo-test-dir/misc/cgo/test &&
PATH=/abuild/rguenther/obj/gotools:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
GCCGO='/abuild/rguenther/obj/gotools/check-gccgo'
CC='/abuild/rguenther/obj/gotools/check-gcc'
GCCGOTOOLDIR='/abuild/rguenther/obj/gotools' GO_TESTING_GOTOOLS=yes
LD_LIBRARY_PATH=/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgo/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libsanitizer/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libmpx/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libvtv/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libssp/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgomp/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libitm/.libs:/abuild/rguenther/obj/x86_64-pc-linux-gnu/libatomic/.libs:/abuild/rguenther/obj/./gcc:/abuild/rguenther/obj/./prev-gcc
GOROOT=/abuild/rguenther/obj/x86_64-pc-linux-gnu/libgo GOTRACEBACK=2
/abuild/rguenther/obj/gotools/go test -test.short -test.v
=== RUN   TestSetgid
--- PASS: TestSetgid (0.00s)
=== RUN   Test6997
--- PASS: Test6997 (0.50s)
=== RUN   TestBuildID
signal: Terminated
FAIL_/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test  
293.646s
--- FAIL: go test misc/cgo/test (0.00s)

so draw conclusions from that.  The cgo/test/buildid_linux.go test somewhat
matches?

[Bug go/83794] misc/cgo/test uses gigabytes of memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
There's other similar fails, like

*** Test killed with Quit: ran too long (10m0s).
exit status 2
FAILcmd/go  600.478s
--- FAIL: go test cmd/go (0.00s)

10 minutes looks excessive to me as well.  Eventually because the machine was
swapping like hell.

For the original issue there's an awful lot of threads (when attaching with
gdb).
One thread is in

#0  sync.Get.pN9_sync.Pool (p=p@entry=0x7ff62c4e63d0 )
at /space/rguenther/src/svn/trunk/libgo/go/sync/pool.go:130
#1  0x7ff62b68e818 in fmt.newPrinter ()
at /space/rguenther/src/svn/trunk/libgo/go/fmt/print.go:133
#2  0x7ff62b696c5e in fmt.Sprintf (format=..., a=...)
at /space/rguenther/src/svn/trunk/libgo/go/fmt/print.go:202
#3  0x7ff62ba0baaa in testing.Logf.pN14_testing.common (c=, 
format=..., args=...)
at /space/rguenther/src/svn/trunk/libgo/go/testing/testing.go:571
#4  0x7ff62ba0baf9 in testing.Logf$stub.pN9_testing.T (
$this20=, $p21=..., $p22=...)
at /space/rguenther/src/svn/trunk/libgo/go/testing/testing.go:476
#5  0x004d6d11 in cgotest.testBuildID (t=)
at
/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test/buildid_linux.go:61
#6  0x004d6fd4 in
__abuild_rguenther_obj_gotools_cgo_test_dir_misc_cgo_test.TestBuildID
(t=)
at
/abuild/rguenther/obj/gotools/cgo-test-dir/misc/cgo/test/cgo_linux_test.go:11

thus logging diagnostics somewhere, eventually gobbling up memory.

I suspect that

namesz := f.ByteOrder.Uint32(d)
descsz := f.ByteOrder.Uint32(d[4:])
typ := f.ByteOrder.Uint32(d[8:])

an := (namesz + 3) &^ 3
ad := (descsz + 3) &^ 3

if int(12+an+ad) > len(d) {
t.Logf("note section %d too short for header
(%d < 12 + align(%d,4) + align(%d,4))", i, len(d), namesz, descsz)
continue
}

is somehow "broken".  Doesn't seem to log to disk anywhere btw?

Ah, and of course after 'continue' this just continues with 'd' unchanged and
thus endlessly loops and logs.  Similar for the earlier error.  I suspect
it wants to continue the outer loop instead?  Or maybe for len (d) > 0 isn't
a loop...

As said, please fix!

[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Created attachment 43099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43099&action=edit
gcc8-pr82682.patch

Untested fix.

[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The effect of the patch on the testcase is:
 .L3:
movzbl  (%edx), %esi
addl$2, %edx
movzbl  -1(%edx), %eax
addl$1, %ecx
-   movl%esi, %ebx
imull   $38470, %eax, %eax
-   movzbl  %bl, %esi
imull   $19595, %esi, %esi
addl%esi, %eax
sarl$16, %eax
movb%al, -1(%ecx)
cmpl%edi, %edx
where the useless movl %esi, %ebx isn't removed by the REE pass itself, but by
rtl_dce later on.  In any case, no extra copy insn is generated in this case,
we just keep around the QI %ebx = QI %esi insn in case the register is used
later on.

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Created attachment 43098 [details]
> > gcc8-pr83590.patch
> 
> > Can you give this a spin?
> 
> Will do.

The patch looks good for openmp, only the usual failures:
...
FAIL: libgomp.c/target-32.c (test for excess errors)
FAIL: libgomp.c/target-33.c execution test
FAIL: libgomp.c/target-34.c execution test
FAIL: libgomp.c/target-link-1.c execution test
FAIL: libgomp.c/thread-limit-2.c (test for excess errors)
FAIL: libgomp.fortran/target2.f90   -O0  execution test
FAIL: libgomp.fortran/target2.f90   -O1  execution test
...

For openacc, the regressions are gone. [ But I see new failures. I've
investigated the first failure, and it's due to a missing cuda.h, which seems
to have gone missing on my nvidia testing laptop. I'm currently reinstalling,
and will retest asap. ]

[Bug target/83768] ARM: wrong optimization

[sorganov at gmail dot com]

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

--- Comment #4 from Sergey Organov  ---
Well, except how one can be sure the cause is actually fixed and not just
[temporary?] hidden, if we only have the fact that it works fine in GCC 6+?

No objection to closing this though, provided no one is interested in
investigating this further.

And, still no idea, even a wild guess, what particular optimization is guilty?

[Bug target/82096] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Does this ICE reproduce with older compilers? We may need to backport the fix
if so

[Bug target/82096] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[sudi at gcc dot gnu.org]

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

--- Comment #9 from sudi at gcc dot gnu.org ---
Yes I at least 6 and 7 need backports. Haven't gone beyond that yet.

[Bug target/82096] [6/7 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ICE in int_mode_for_mode,   |[6/7 Regression] ICE in
   |at stor-layout.c:403 with   |int_mode_for_mode, at
   |arm-linux-gnueabi   |stor-layout.c:403 with
   ||arm-linux-gnueabi

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Adjusting regression markers. GCC 6 is the oldest release we maintain for now,
so we only need backports for 6 and 7

[Bug c++/83796] New: Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

[johnsonmichaelgraham at gmail dot com]

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

Bug ID: 83796
   Summary: Abstract classes allowed to be instantiated when
initialised as default parameter to function or
constructor
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johnsonmichaelgraham at gmail dot com
  Target Milestone: ---

Test Case:

class MyAbstractClass
{
public:
virtual int foo() const = 0;
};

class TestClass
{
public:
TestClass(const MyAbstractClass& m = {}) // should generate compiler error
: value_(m.foo()) {}

int value_;
};

int TestFunction(const MyAbstractClass& m = {}) // should generate compiler
error
{
return m.foo();
}

int main(int argc, char *argv[])
{
TestClass testInstance;

std::cout << testInstance.value_ << std::endl;

std::cout << TestFunction() << std::endl;

return 0;
}

// Compiles OK

runtime output:

pure virtual method called
terminate called without an active exception

[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV

[rguenth at gcc dot gnu.org]

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

--- Comment #60 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 11 12:12:39 2018
New Revision: 256528

URL: https://gcc.gnu.org/viewcvs?rev=256528&root=gcc&view=rev
Log:
2018-01-11  Richard Biener  
Rainer Orth  

PR lto/81968
libiberty/
* simple-object-common.h (struct simple_object_functions):
Change copy_lto_debug_sections callback signature.
* simple-object-elf.c (SHN_HIRESERVE, SHT_SYMTAB_SHNDX,
SHF_INFO_LINK): Add defines.
(simple_object_elf_copy_lto_debug_sections): Instead of
leaving not to be copied sections empty unnamed SHT_NULL
remove them from the target section headers and adjust section
reference everywhere.  Handle SHN_XINDEX in the symbol table
processing properly.
* simple-object.c (handle_lto_debug_sections): Change
interface to return a modified string and handle renaming
of relocation sections.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/simple-object-common.h
trunk/libiberty/simple-object-elf.c
trunk/libiberty/simple-object.c

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Thu Jan 11 12:13:42 2018
New Revision: 256529

URL: https://gcc.gnu.org/viewcvs?rev=256529&root=gcc&view=rev
Log:
2018-01-11  Prathamesh Kulkarni  

PR target/83514
* config/arm/arm.c (arm_declare_function_name): Set arch_to_print if
targ_options->x_arm_arch_string is non NULL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug tree-optimization/83189] [8 regression] internal compiler error: in probability_in, at profile-count.h:1050

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed then.

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #6 from prathamesh3492 at gcc dot gnu.org ---
Committed patch to conditionally set arch_to_print after Kyrill's approval.

Thanks,
Prathamesh

[Bug tree-optimization/83288] [8 Regression] polyhedron gas_dyn 2-fold compile-time regression caused by r255103

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
It recovered indeed.

[Bug c++/83797] New: Inconsistent error messages for main

[denis.campredon at gmail dot com]

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

Bug ID: 83797
   Summary: Inconsistent error messages for main
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

In the following snippet:
-
inline static constexpr short main() {
}
-
1 : :1:36: error: cannot declare '::main' to be inline
 inline static constexpr short main() {
^
1 : :1:36: error: cannot declare '::main' to be 'constexpr'
1 : :1:36: error: cannot declare '::main' to be static
1 : :1:36: error: '::main' must return 'int'
-

'int' and 'constexpr' are quoted whereas 'inline' and 'static' are not.



In this one 'main' is not preceded by '::' whereas in all the previous warnings
it is.

main()  {}

1 : :1:6: warning: ISO C++ forbids declaration of 'main' with no type
[-Wreturn-type]
 main(){}
  ^

[Bug libgomp/83590] [nvptx] openacc reduction C regressions

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> [ But I see new failures. I've
> investigated the first failure, and it's due to a missing cuda.h, which
> seems to have gone missing on my nvidia testing laptop. I'm currently
> reinstalling, and will retest asap. ]

Confirmed, all those new failures are gone now.

And, I forgot to mention: the example from comment 1 works fine as well.


So, in summary: no problems found in libgomp testing of patch at r256524 for
x86_64 with nvptx accelerator and GOMP_NVPTX_JIT=-O0 (to filter out nvidia
driver problems), cuda 7.5 and driver version 384.111 on ubuntu 16.04.3.

[Bug other/83786] Add VEC_ORDERED_REMOVE_IF

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Latest version: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00899.html

[Bug c++/83798] New: Enhancement to Wmain warnings

[denis.campredon at gmail dot com]

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

Bug ID: 83798
   Summary: Enhancement to Wmain warnings
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Compiled with g++ the following code produces some rather confusing warnings:
---
int main(short s, void** t, int** u, int** v) {}
---
1 : :1:5: warning: first argument of 'int main(short int, void**,
int**, int**)' should be 'int' [-Wmain]
 int main(short s, void** t, int** u, int** v) {}
 ^~~~
1 : :1:5: warning: second argument of 'int main(short int, void**,
int**, int**)' should be 'char **' [-Wmain]
1 : :1:5: warning: third argument of 'int main(short int, void**,
int**, int**)' should probably be 'char **' [-Wmain]
1 : :1:5: warning: 'int main(short int, void**, int**, int**)' takes
only zero or two arguments [-Wmain]
---

In the first three warnings, just '::main' should be displayed, like when
compiled with gcc, instead of the full signature.
For the fourth one, we can see that gcc also accepts three arguments in main,
for the env, not only 0 or 2.

[Bug c++/78609] invalid member's visibility detection in constexpr

[matthijs at stdin dot nl]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #2 from Matthijs Kooijman  ---
I also ran into this problem. It seems that gcc somehow inlines c_str() (or
rather, evaluates the constexpr variable it is assigned to) before visibility
checks (possibly because the constexpr is evaluated before template
initialization?).

Below is a smaller example, which is confirmed broken up to gcc 8. I could not
reduce this example any further, so it seems the essential pattern that
triggers this is:
 - There is a class instance in a constexpr variable with static storage
duration
 - A pointer to a private member of this object is accessed through a method
 - This pointer is assigned to a constexpr variable
 - This pointer is assigned in a template instantiation

Here's the code:

  class foo {
  char c;
public:
  //constexpr foo(): c(1) { }
  //constexpr foo(char c): c(c) { }
  constexpr const char* c_str() const { return &c; }
  };

  constexpr foo basename = foo(); // Fails
  // These also fail, if you add the appropriate constructor above
  //static constexpr foo basename = foo(1); // Fails
  //static constexpr foo basename(1); // Fails
  //static constexpr foo basename{1}; // Fails
  //static constexpr foo basename{}; // Fails
  // Surprisingly this works (but needs a constructor above):
  //static constexpr foo basename; // Works

  template 
  void call() {
// This is where it breaks
constexpr const char *unused = basename.c_str();
  }

  int main() {
// Instantiate the call function
call();
  }

  // Removing the template argument on T makes it work
  // Letting T be deduced by adding an argument to call() also fails
  // Making the "unused" variable non-constexpr makes it work
  // Making get() return c instead of &c makes it work
  // Making "basename" a static variable inside call() also fails
  //
  // Tested on avr-gcc avr-gcc 4.9.2, gcc Debian 6.3.0-18, gcc Debian
  // 7.2.0-19, gcc Debian 8-20180110-1


$ avr-gcc ATest.cpp -std=c++11
ATest.cpp: In instantiation of ‘void call() [with T = int]’:
ATest.cpp:26:13:   required from here
ATest.cpp:2:10: error: ‘char foo::c’ is private
 char c;
  ^
ATest.cpp:21:49: error: within this context
   constexpr const char *unused = basename.c_str();
 ^

[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||sudi at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |sudi at gcc dot gnu.org

[Bug c++/83799] New: [8 Regression] bogus "no matching function for call to" error when building llvm

[trippels at gcc dot gnu.org]

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

Bug ID: 83799
   Summary: [8 Regression] bogus "no matching function for call
to" error when building llvm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43100&action=edit
unreduced testcase

trippels@gcc2-power8 llvm_build % /home/trippels/gcc_test/usr/local/bin/g++ 
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/CodeGen
-I/home/trippels/llvm/llvm/lib/CodeGen -Iinclude
-I/home/trippels/llvm/llvm/include -fPIC -fvisibility-inlines-hidden
-Werror=date-time -std=c++11 -Wall -W
 -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunct
ion-sections -fdata-sections -Wno-implicit-fallthrough -Wno-class-memaccess
-fdiagnostics-color=always -O3 -pipe -UNDEBUG -fno-exceptions -fno-rtti -MD -MT
lib/CodeGen/CMakeFiles/
LLVMCodeGen.dir/BasicTargetTransformInfo.cpp.o -MF
lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/BasicTargetTransformInfo.cpp.o.d -o
lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/BasicTargetTra
nsformInfo.cpp.o -c
/home/trippels/llvm/llvm/lib/CodeGen/BasicTargetTransformInfo.cpp   
In file included from
/home/trippels/llvm/llvm/lib/CodeGen/BasicTargetTransformInfo.cpp:18:
/home/trippels/llvm/llvm/include/llvm/CodeGen/BasicTTIImpl.h: In member
function ‘bool llvm::BasicTTIImplBase::haveFastSqrt(llvm::Type*)’:
/home/trippels/llvm/llvm/include/llvm/CodeGen/BasicTTIImpl.h:295:38: error: no
matching function for call to
‘llvm::TargetLoweringBase::getValueType(llvm::TargetTransformInfoImplB
ase, llvm::Type*&) const’
 EVT VT = TLI->getValueType(DL, Ty);
  ^
In file included from
/home/trippels/llvm/llvm/include/llvm/CodeGen/BasicTTIImpl.h:30,
 from
/home/trippels/llvm/llvm/lib/CodeGen/BasicTargetTransformInfo.cpp:18:
/home/trippels/llvm/llvm/include/llvm/CodeGen/TargetLowering.h:1023:7: note:
candidate: ‘llvm::EVT llvm::TargetLoweringBase::getValueType(const
llvm::DataLayout&, llvm::Type*, bool) const’
   EVT getValueType(const DataLayout &DL, Type *Ty,
   ^~~~
/home/trippels/llvm/llvm/include/llvm/CodeGen/TargetLowering.h:1023:7: note:  
no known conversion for argument 1 from ‘llvm::TargetTransformInfoImplBase’ to
‘const llvm::DataLayo
ut&’
...etc.

Was fine yesterday.

[Bug tree-optimization/83435] [8 Regression] ICE in set_value_range, at tree-vrp.c:211

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug c/83800] New: [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?

[sisyphus1 at optusnet dot com.au]

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

Bug ID: 83800
   Summary: [libquadmath] M_SQRT2q & sqrtq(2.0Q) off by one ULP ?
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sisyphus1 at optusnet dot com.au
  Target Milestone: ---

Hi,

Why does quadmath.h define M_SQRT2q to be 1.4142135623730950488016887242096981Q
(0x1.6a09e667f3bcc908b2fb1366ea96p+0) when a closer approximation is
0x1.6a09e667f3bcc908b2fb1366ea95p+0 ?

If I've calculated it correctly:
0x1.6a.96p+0 exceeds sqrt(2) by approx 9.84e-35.
0x1.6a.95p+0  falls short of sqrt(2) by approx 9.42e-35, and is therefore
the nearest value.

And 0x1.6a.95p+0 is the value that the MPFR library returns for sqrt(2) for
113-bit precision, rounded to nearest.

Is this a bug in gcc ?  or are there mitigating factors to be considered ?

Note also that sqrtq(2.0Q) returns the "wrong" value of 0x1.6a.96p+0.
In fact, it seems that sqrtq(x) returns a significand of 0x1.6a.96p
whenever x is a power of 2 that has an irrational square root.

Cheers,
Rob

[Bug tree-optimization/83435] [8 Regression] ICE in set_value_range, at tree-vrp.c:211

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Jan 11 13:42:29 2018
New Revision: 256535

URL: https://gcc.gnu.org/viewcvs?rev=256535&root=gcc&view=rev
Log:
2018-01-11  Richard Biener  

PR tree-optimization/83435
* graphite.c (canonicalize_loop_form): Ignore fake loop exit edges.
* graphite-scop-detection.c (scop_detection::get_sese): Likewise.
* tree-vrp.c (add_assert_info): Drop TREE_OVERFLOW if they appear.

* gcc.dg/graphite/pr83435.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83435.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug c++/83777] Invalid dependent initialization of a static data member.

[Zahira.Ammarguellat at intel dot com]

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

--- Comment #2 from Zahira Ammarguellat  
---
>From my understanding, the test case is trying to instantiate "C" with "void *"
type, which doesn't have a member called "M". 
I think this should generate an error?

Clang and MSVC both give an error compiling this test case.

bash-4.2$ cat 8528.cpp
template  class C
{
  static const int BlockSize = T::M;
public:
  static const int type = 1;
};

int foo() { return C::type == 1; }
bash-4.2$

bash-4.2$ clang -v
clang version 6.0.0
bash-4.2$ clang -c 8528.cpp
8528.cpp:3:32: error: type 'void *' cannot be used prior to '::' because it has
  no members
  static const int BlockSize = T::M;
   ^
8528.cpp:8:20: note: in instantiation of template class 'C' requested
  here
int foo() { return C::type == 1; }
   ^
1 error generated.
bash-4.2$
ksh-3.2$ cl -c 8528.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

8528.cpp
8528.cpp(3): error C2825: 'T': must be a class or namespace when followed by
'::'
8528.cpp(8): note: see reference to class template instantiation 'C'
being compiled
8528.cpp(3): error C2510: 'T': left of '::' must be a class/struct/union
8528.cpp(3): error C2065: 'M': undeclared identifier
8528.cpp(3): error C2131: expression did not evaluate to a constant
8528.cpp(3): note: failure was caused by non-constant arguments or reference to
a non-constant symbol
8528.cpp(3): note: see usage of 'M'
ksh-3.2$

[Bug target/83801] New: [avr] String constant in __flash not put into .progmem

[gjl at gcc dot gnu.org]

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

Bug ID: 83801
   Summary: [avr] String constant in __flash not put into .progmem
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

char to_ascii (unsigned i)
{
static const char __flash code_tab[] = "0123456789";
return code_tab[i];
}

In the above test case, code_tab is put into .rodata instead of into .progmem.

[Bug target/83801] [avr] String constant in __flash not put into .progmem

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
 CC||gandalf at winds dot org
 Ever confirmed|0   |1

[Bug middle-end/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
(In reply to gandalf from comment #3)
> Another regression test case (compile with -O):
> 
> void code_to_ascii(char buf[1], unsigned int code)
> {
>   __attribute__((used))
>   static const char __flash test[5]="ABCDE";
> 
>   static const char __flash code_tab[32]="0123456789ABCDEFGHJKLMNPRSTUWXYZ";
> 
>   buf[0]=code_tab[code];
> }
> 
> Variable "code_tab" is incorrectly placed in section .rodata.

Different issue, likely a target thing.  Filed as PR83801.

[Bug c++/83799] [8 Regression] bogus "no matching function for call to" error when building llvm

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1
 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Started with r256448.

[Bug c++/83799] [8 Regression] bogus "no matching function for call to" error when building llvm

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #6 from Segher Boessenkool  ---
It's in 7 and later; not planning on backporting it to 6 anymore.

[Bug c++/83802] New: Caller doesn't destroy default argument passed to a constructor

[pdziepak at quarnos dot org]

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

Bug ID: 83802
   Summary: Caller doesn't destroy default argument passed to a
constructor
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdziepak at quarnos dot org
  Target Milestone: ---

Godbolt link: https://godbolt.org/g/fBbYgF

When the following code is compiled with -std=c++17:

struct foo {
~foo();
};
extern foo f;

struct bar {
bar(int, foo = f);
};

void fn()
{
bar b(0);
}

...the destructor of the copy of f passed to the bar's constructor is never
called:

fn():
  pushq %rbp
  movq %rsp, %rbp
  subq $16, %rsp
  leaq -1(%rbp), %rdx
  leaq -2(%rbp), %rax
  movl $0, %esi
  movq %rax, %rdi
  call bar::bar(int, foo)
  nop
  leave
  ret

[Bug target/79140] gcc.target/powerpc/ssp-1.c fails starting with its introduction in r244562

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
.

[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

[matthew at wil dot cx]

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

--- Comment #7 from Matthew Wilcox  ---
OK, so how should we write this function/macro to accomplish what we want?

And the requirement is "If the argument is one of these eight special
constants, use this special instruction, otherwise call this function".  Even
if the argument happens to be one of the eight special values at runtime, we
should still call the function, because it's not worth doing runtime checks; we
only want a compile-time optimisation.  And it's worth the compile-time
optimisation because adding constant 1/-1 is really, really common.

[Bug fortran/83803] New: Using -fc-prototypes on modules with empty dummy arg lists does not close paren.

[3dw4rd at verizon dot net]

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

Bug ID: 83803
   Summary: Using -fc-prototypes on modules with empty dummy arg
lists does not close paren.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 3dw4rd at verizon dot net
  Target Milestone: ---

Created attachment 43101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43101&action=edit
nocloseparen.f95 module.

The following module:
--
module voidfunc

  use iso_c_binding

  integer :: fvflag

contains

  subroutine zeroflag() bind(c)
fvflag = 0
  end subroutine

  integer(c_int) function showflag() bind(c)
showflag = fvflag
  end function

end module
--

Generates the following prototype:
$ ./bin/gfortran -c -fc-prototypes nocloseparen.f95 
int showflag (;
void zeroflag (;
$ 

No crashes or ICEs.

Compiler info:

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Indeed it looks like the testcase has been failing with -fno-vect-cost-model
for a very long time.

Trying the find the 'good' starting point for a bisect.

(I'm using qemu, I have no such board either)

[Bug debug/68860] [6/7/8 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #20 from Richard Biener  ---
Yes, early LTO debug is in now.  While we can probably stream DECL_DEBUG_EXPR
directly as we do now given that is set only for function-local decls we can't
do that for FUNCTION_DECLs which are global entities that are subject to
merging.
Instead we need to stream this for the instances, possibly at the time we
stream struct function.

I'll experiment with this a bit.

[Bug debug/68860] [6/7/8 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to Richard Biener from comment #20)
> Yes, early LTO debug is in now.  While we can probably stream
> DECL_DEBUG_EXPR directly as we do now given that is set only for
> function-local decls we can't do that for FUNCTION_DECLs which are global
> entities that are subject to merging.
> Instead we need to stream this for the instances, possibly at the time we
> stream struct function.
> 
> I'll experiment with this a bit.

Huh, no, they are applied at the call site during var-tracking rather than
in the callee prologue.

Still, in that case we probably need to "compare" them in compare_tree_sccs_1.

[Bug c++/83799] [8 Regression] bogus "no matching function for call to" error when building llvm

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-11
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Confirmed.  Thanks for filing this.  Am investigating.

[Bug lto/83804] New: [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

Bug ID: 83804
   Summary: [meta] LTO memory consumption
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz, jamborm at gcc dot gnu.org,
marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

I'm creating this PR to track a bit memory consumption of LTO. As Richi merged
early debug changes in time of GCC stage1, let use the PR to track memory
footprint.

I'm going to attach numbers for current head of GCC-7 branch and current trunk.
Both are with --enable-gather-detailed-mem-stats, so memory usage is bit higher
due to all scaffolding needed for -fmem-report.

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 43102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43102&action=edit
-fmem-report-wpa for Inkscape with -O2 for GCC 7

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 43103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43103&action=edit
-fmem-report-wpa for Inkscape with -O2 for GCC 8

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 43104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43104&action=edit
CPU & memory consumption for Inkscape with GCC 7

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 43105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43105&action=edit
CPU & memory consumption for Inkscape with GCC 8

[Bug lto/83804] [meta] LTO memory consumption

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So comparing memory footprint of GCC 7 and GCC 8, I see small increase for WPA
phase (~5%).

[Bug target/83203] [8 Regression] Inefficient int to avx2 vector conversion

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Created attachment 43106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43106&action=edit
gcc8-pr83203.patch

Untested fix.

[Bug fortran/79383] USE statement error

[walt.brainerd at gmail dot com]

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

--- Comment #3 from Walt Brainerd  ---
Yes, Sounds like you have it fixed. Thanks.

On Wed, Jan 10, 2018 at 7:06 PM, kargl at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383
>
> kargl at gcc dot gnu.org changed:
>
>What|Removed |Added
> 
> 
>  CC||kargl at gcc dot gnu.org
>
> --- Comment #2 from kargl at gcc dot gnu.org ---
> The attached code compiles with both 7-branch an trunk.
> When the resulting excutable is run I get 15.10 on output.
> Is this the expected behavior?
>
> --
> You are receiving this mail because:
> You reported the bug.