[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
For aarch64-none-elf it fails during.

01:53:39 checking for dirent.h that defines DIR... no
01:53:39 checking for sys/ndir.h that defines DIR... no
01:53:39 checking for sys/dir.h that defines DIR... no
01:53:39 checking for ndir.h that defines DIR... no
01:53:39 checking for library containing opendir... configure: error:
Link tests are not allowed after GCC_NO_EXECUTABLES.
01:53:39 Makefile:10143: recipe for target
'configure-target-libstdc++-v3' failed
01:53:39 make[1]: *** [configure-target-libstdc++-v3] Error 1

this error comes from (in libstdc++-v3/configure.ac which was not
present in 4.9 branch)

This comes from:
# For Filesystem TS.
AC_CHECK_HEADERS([fcntl.h dirent.h sys/statvfs.h utime.h])
AC_STRUCT_DIRENT_D_TYPE
GLIBCXX_ENABLE_FILESYSTEM_TS
GLIBCXX_CHECK_FILESYSTEM_DEPS

According to the documentation:
— Macro: AC_STRUCT_DIRENT_D_TYPE
Perform all the actions of AC_HEADER_DIRENT (see Particular
Headers). Then, if struct dirent contains a d_type member, define
HAVE_STRUCT_DIRENT_D_TYPE.

and:
Macro: AC_HEADER_DIRENT
Check for the following header files. For the first one that is
found and defines `DIR', define the listed C preprocessor macro:

`dirent.h'  HAVE_DIRENT_H
`sys/ndir.h'HAVE_SYS_NDIR_H
`sys/dir.h' HAVE_SYS_DIR_H
`ndir.h'HAVE_NDIR_H

Is libstdc++-v3 supposed to ignore this or should newlib supposed to have this
defined in the appropriate header?

[Bug inline-asm/65897] GAS(asm) "named variable" of extended asm (type ::"m" or "g") generated in wrong code style, variable stays still in ".att_syntax" -32(%ebp) not ".intel_syntax noprefix" DWORD P

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Jakub Jelinek  ---
Please stop reopening this, it is really not a bug.  GCC intentionally does not
try to semantically analyze the inline asm template, for the compiler it is
meant to be an arbitrary text in which it performs string replacements.
If you don't like ATT syntax, just use -masm=intel globally, or you can change
it within inline asm iff you change it back and don't have any % arguments in
between those two (because, obviously the compiler does not and should not know
you've switched the syntax in between).

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
Looking at libstdc++'s config.log, I noticed that GCC_NO_EXECUTABLES is set
because the default GCC link command fails on aarch64-none-elf and
arm-none-eabi --with-mode=thumb because librdimon.a is not used by default.

Could it be that this opendir test is the first link test in libstc++'s
configure for those targets? (And thus that the above problem was unnoticed for
months?)

[Bug rtl-optimization/66048] [i386] ICE in create_pre_exit when both AVX and MPX are used

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed May 13 07:49:59 2015
New Revision: 223114

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

PR target/66048
* function.c (diddle_return_value_1): Process bounds first.
* config/i38/i386.c (ix86_function_value_regno_p): Add bnd1
register.

gcc/testsuite/

PR target/66048
* gcc.target/i386/mpx/pr66048.cc: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr66048.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers

[robert.suchanek at imgtec dot com]

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

--- Comment #12 from Robert Suchanek  ---
Thanks Vlad.

The regression in clean on MIPS. I'll send a patch along with the testcase(s)
once the core part it's committed on the trunk.

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 13 08:07:58 2015
New Revision: 223115

URL: https://gcc.gnu.org/viewcvs?rev=223115&root=gcc&view=rev
Log:
PR target/66112
* internal-fn.c (get_min_precision): Use UNSIGNED instead of
SIGNED to get precision of non-negative value.

* gcc.target/i386/pr66112-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66112-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 13 08:09:01 2015
New Revision: 223116

URL: https://gcc.gnu.org/viewcvs?rev=223116&root=gcc&view=rev
Log:
PR target/66112
* config/i386/i386.md (mulv4, umulv4, *umulv4):
Use SWI248 iterator instead of SWI.
(*mulv4_1): Use SWI48 instead of SWI.  Simplify output template.
Use eq_attr "alternative" "0" instead of match_test in
length_immediate attribute computation.
(*mulvhi4, *mulvhi4_1): New define_insns.

* gcc.target/i386/pr66112-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66112-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/66112] __builtin_mul_overflow for int16_t emits poor code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.  Not a regression, so probably not suitable for
backporting.

[Bug target/65103] [i386] GOTOFF relocation is not propagated into address expression

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed May 13 08:29:14 2015
New Revision: 223119

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

PR target/65103
* config/i386/i386.c (ix86_rtx_costs): We want to propagate
link time constants into adress expressions and therefore set
their cost to 0.

gcc/testsuite/

PR target/65103
* gcc.target/i386/pr65103-3.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65103-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/66090] Wrong loop code generation with -O2 on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
The testcase computes ptr + 1024 which evaluates to zero (even without IVOPTs
coming into play).  This invokes undefined behavior as even if you consider
ptr + 1024 being "one after the last array element and not dereferenced"
(the NULL pointer is special in C, if you want to lift this restriction you
need to provide -fno-delete-null-pointer-checks).

Joseph may be able to provide more C standard legalise wording here.  But it's
certainly how the middle-end works.

[Bug c/66090] Wrong loop code generation with -O2 on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm, i?86-*-*

--- Comment #5 from Richard Biener  ---
Reproducible on i?86 as well, btw.

[Bug tree-optimization/66129] [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-13
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
Setting LDFLAGS_FOR_TARGET=-specs=rdimon.specs works for me for
aarch64-none-elf.

Is it expected that we have to use such settings for the build to succeed?

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed May 13 09:06:18 2015
New Revision: 223120

URL: https://gcc.gnu.org/viewcvs?rev=223120&root=gcc&view=rev
Log:
Gimplify va_arg ap based on do_deref

2015-05-13  Tom de Vries  

PR tree-optimization/66010
* gimplify.h (gimplify_va_arg_internal): Remove declaration.
* gimplify.c (gimplify_va_arg_internal): Remove and inline into ...
* tree-stdarg.c (expand_ifn_va_arg_1): ... here.  Choose between lval
and rval based on do_deref.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/gimplify.h
trunk/gcc/tree-stdarg.c

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
FTR, patch submission for follow-up patch:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01178.html .

[Bug tree-optimization/66129] [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Oops...

Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 223119)
+++ tree-vect-slp.c (working copy)
@@ -3459,7 +3459,7 @@ vect_schedule_slp_instance (slp_tree nod
  tree *melts = XALLOCAVEC (tree, TYPE_VECTOR_SUBPARTS (vectype));
  for (l = 0; l < TYPE_VECTOR_SUBPARTS (vectype); ++l)
{
- if (k > group_size)
+ if (k >= group_size)
k = 0;
  melts[l] = build_int_cst
  (meltype, mask[k++] * TYPE_VECTOR_SUBPARTS (vectype) +
l);

[Bug fortran/66100] [6 Regression] ICE in simplify_bound

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org

--- Comment #3 from Mikael Morin  ---
This should be fixed.

[Bug tree-optimization/65447] AArch64: iv-opt causes bad addressing

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Patch for review at https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00641.html

[Bug tree-optimization/63602] [5/6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

  Known to work||4.9.2
Summary|Wrong code w/ -O2   |[5/6 Regression] Wrong code
   |-ftree-loop-linear  |w/ -O2 -ftree-loop-linear
  Known to fail|4.8.3, 4.9.1, 5.0   |5.1.0, 6.0

--- Comment #2 from Arseny Solokha  ---
I've just checked it and found that gcc 4.9.2 compiles it correctly. So,
relabelling as a regression.

[Bug tree-optimization/66131] New: [6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[asolokha at gmx dot com]

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

Bug ID: 66131
   Summary: [6 Regression] Wrong code w/ -O2 -ftree-loop-linear
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc produces wrong code w/ -ftree-loop-linear -O2 (and above) for the following
reduced case:

int fk = 0;
int vm, ft;

static int
qr(void)
{
  int *op[33] = { &fk };
  int **ts[1] = { &op[0] };
  for (fk = 0; fk < 2; ++fk)
for (ft = 0; ft < 1; ++ft)
  vm = fk;
  return 0;
}

static int
ay(void)
{
  int yc;
  for (ft = 0; ft < 1; ++ft)
for (vm = 0; vm < 1; ++vm) {
  fk |= 1;
  return qr();
}
  for (fk = 0; fk < 1; ++fk)
for (yc = 0; yc < 2; ++yc)
  for (vm = 0; vm < 1; ++vm)
for (ft = 0; ft < 1; ++ft) {
}
  return 0;
}

int
main(void)
{
  ay();
  return vm != 1;
}

Expected results:
% gcc-6.0.0-alpha20150503 -ftree-loop-linear -O2 -Wall -Wextra -Wpedantic
dfc7c304.c
% ./a.out
% echo $?
0

Actual results:
% gcc-6.0.0-alpha20150503 -ftree-loop-linear -O2 -Wall -Wextra -Wpedantic
dfc7c304.c
% ./a.out
% echo $?
1

This issue may be somewhat similar to PR63602.

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed May 13 10:53:42 2015
New Revision: 223126

URL: https://gcc.gnu.org/viewcvs?rev=223126&root=gcc&view=rev
Log:
2015-05-13  Richard Biener  

PR middle-end/66110
* alias.c (alias_sets_conflict_p): Do not treat has_zero_child
specially.
* Makefile.in (dfp.o-warn): Add -Wno-strict-aliasing.

* gcc.dg/alias-2.c: Adjust.
* gcc.dg/tree-ssa/ssa-dse-17.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/alias.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/alias-2.c

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk.

[Bug target/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org
Version|4.8.1   |6.0

--- Comment #9 from Maxim Ostapenko  ---
Add ARM maintainers.

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to James Greenhalgh from comment #7)
> (In reply to Richard Biener from comment #5)
> > DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
> >   "sra-max-scalarization-size-Ospeed",
> >   "Maximum size, in storage units, 
> > 
> > storage units!  But the value seems to be in bits?  It gets used as
> > 
> > if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
> > <= max_scalarization_size)
> > 
> 
> Well, that part should have been covered by:
> 
> +  unsigned max_scalarization_size
> += (optimize_function_for_size_p (cfun)
> + ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
> + : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED))
> +  * BITS_PER_UNIT;
> 
> From the original patch, 
> 
> > Looks like get_move_ratio returns different things at SRA time (if I re-call
> > it)
> > and the time it gets invoked in toplev.c.
> 
> But, yes these parameters will cause a difference in code generation if
> previously MOVE_RATIO could return different values at different times, as
> it might well have if target_option_override set up a structure used by
> MOVE_RATIO.
> 
> The patch I applied carries the hidden assumption that MOVE_RATIO is
> constant. Clearly there are a number of situations we might not want that to
> be true (say, for switchable targets - which I don't think your patch will
> help).

So maybe instead compute that "default" in SRA itself?

[Bug tree-optimization/66123] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed May 13 10:59:49 2015
New Revision: 223130

URL: https://gcc.gnu.org/viewcvs?rev=223130&root=gcc&view=rev
Log:
2015-05-13  Richard Biener  

PR tree-optimization/66123
* tree-ssa-dom.c (propagate_rhs_into_lhs): Check if we found
a taken edge.

* gcc.dg/torture/pr66123.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66123.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/66123] [4.8/4.9/5 Regression] Array of labels as values + ternary operator + pointer arithmetic = internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.3.4, 6.0
Version|unknown |5.1.0
   Target Milestone|--- |4.8.5
Summary|Array of labels as values + |[4.8/4.9/5 Regression]
   |ternary operator + pointer  |Array of labels as values +
   |arithmetic = internal   |ternary operator + pointer
   |compiler error  |arithmetic = internal
   ||compiler error
  Known to fail||4.6.4

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c/66122] Bad uninlining decisions

[vda.linux at googlemail dot com]

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

--- Comment #6 from Denis Vlasenko  ---
Got a hold on a machine with gcc version 5.1.1 20150422 (Red Hat 5.1.1-1)

Pulled current Linus kernel tree and built it with this config:
http://busybox.net/~vda/kernel_config2
Note that "CONFIG_CC_OPTIMIZE_FOR_SIZE is not set", i.e. it's a -O2 build.

Selecting duplicate functions still shows a number of tiny uninlined functions:

$ nm --size-sort vmlinux | grep -iF ' t ' | uniq -c | grep -v '^ *1 ' | sort
-rn
 83 008a t rcu_read_lock_sched_held
 48 001b t sd_driver_init
 48 0012 t sd_driver_exit
 48 0008 t __initcall_sd_driver_init6
 47 0020 t usb_serial_module_init
 47 0012 t usb_serial_module_exit
 47 0008 t __initcall_usb_serial_module_init6
 45 0057 t uni2char
 45 0025 t char2uni
 43 001f t sd_probe
 40 006a t rcu_read_unlock
 29 005a t cpumask_next
 27 007a t rcu_read_lock
 27 0011 t kzalloc
 24 0022 t arch_local_save_flags
 23 0041 t cpumask_check
 19 0017 t phy_module_init
 19 0017 t phy_module_exit
 19 0008 t __initcall_phy_module_init6
 18 006c t spi_write
 18 003f t show_alarm
 18 000b t bitmap_weight
 15 0037 t show_alarms
 15 0014 t init_once
 14 0603 t init_engine
 14 0354 t pcm_trigger
 14 033b t pcm_open
 14 00f8 t stop_transport
 14 00db t pcm_close
 14 00c8 t set_meters_on
 14 00b5 t write_dsp
 14 00b5 t pcm_hw_free
 14 0091 t pcm_pointer
 14 0090 t hw_rule_playback_channels_by_format
 14 008d t send_vector
 14 004f t snd_echo_vumeters_info
 14 0042 t hw_rule_sample_rate
 14 003e t snd_echo_vumeters_switch_put
 14 0034 t audiopipe_free
 14 002b t snd_echo_channels_info_info
 14 0024 t snd_echo_remove
 14 001b t echo_driver_init
 14 0019 t pcm_analog_out_hw_params
 14 0019 t arch_local_irq_restore
 14 0014 t snd_echo_dev_free
 14 0012 t echo_driver_exit
 14 0008 t __initcall_echo_driver_init6
 13 0127 t pcm_analog_out_open
 13 0127 t pcm_analog_in_open
 13 0039 t qdisc_peek_dequeued
 13 0037 t cpumask_check
 13 0022 t arch_local_irq_restore
 13 001c t pcm_analog_in_hw_params
 13 0006 t bcma_host_soc_unregister_driver
 12 0053 t nlmsg_trim
...

Such as:
811a42e0 :
811a42e0:   55  push   %rbp
811a42e1:   81 ce 00 80 00 00   or $0x8000,%esi
811a42e7:   48 89 e5mov%rsp,%rbp
811a42ea:   e8 f1 92 1a 00  callq  <__kmalloc>
811a42ef:   5d  pop%rbp
811a42f0:   c3  retq

810792d0 :
810792d0:   55  push   %rbp
810792d1:   48 89 e5mov%rsp,%rbp
810792d4:   e8 37 a8 b7 00  callq  <__bitmap_weight>
810792d9:   5d  pop%rbp
810792da:   c3  retq

and even
88566c9b :
88566c9b:   55  push   %rbp
88566c9c:   48 89 e5mov%rsp,%rbp
88566c9f:   5d  pop%rbp
88566ca0:   c3  retq

This is an *empty function* from drivers/bcma/bcma_private.h:103 uninlined:
static inline void __exit bcma_host_soc_unregister_driver(void)
{
}

BTW it doesn't even have any callers in vmlinux. It should have been optimized
out.

[Bug tree-optimization/66131] [6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/66127] Division by zero gets folded away

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note that the inconsistent handling of */% 0 has been 1:1 translated from
fold-const.c (also the comments).

[Bug c/66122] Bad uninlining decisions

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
You can look at -Winline output

[Bug c/66132] New: Undefined reference to inline function

[shea at shealevy dot com]

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

Bug ID: 66132
   Summary: Undefined reference to inline function
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shea at shealevy dot com
  Target Milestone: ---

When compiling with the default optimization level, this code:

inline int foo() {
return 1;
}

int main(int argc, char ** argv) {
return foo();
}

results in an undefined reference error:

/tmp/ccRBjwvf.o: In function `main':
test.c:(.text+0x15): undefined reference to `foo'
collect2: error: ld returned 1 exit status

This goes away at -O2 (presumably because the function is actually inlined?)

[Bug c/66132] Undefined reference to inline function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Markus Trippelsdorf  ---
https://gcc.gnu.org/gcc-5/porting_to.html

[Bug c/66132] Undefined reference to inline function

[shea at shealevy dot com]

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

--- Comment #2 from Shea Levy  ---
(In reply to Markus Trippelsdorf from comment #1)
> https://gcc.gnu.org/gcc-5/porting_to.html

I see, sorry for the noise!

[Bug middle-end/66133] New: Wrong-code with noreturn #pragma omp task body

[jakub at gcc dot gnu.org]

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

Bug ID: 66133
   Summary: Wrong-code with noreturn #pragma omp task body
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

When working on #pragma omp taskloop support, I've noticed we handle badly
#pragma omp task constructs if the task's body never returns.

E.g.:

#include 
#include 

volatile int x;

__attribute__((noinline)) void
foo (void)
{
  if (x == 0)
{
  #pragma omp task
{
  usleep (2000);
  exit (0);
}
}
  else
abort ();
}

int
main ()
{
  #pragma omp parallel num_threads (1)
{
  #pragma omp barrier
  #pragma omp single
foo ();
}
  exit (0);
}

[Bug middle-end/66127] Division by zero gets folded away

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-13
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #5 from Marek Polacek  ---
I have some patch...

[Bug rtl-optimization/30967] Extra sign/zero extend with word comparison result

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-13
 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
Still happening.  The problem now is that eq:SI is costed as one insn
(which it is not), but eq:DI as three.

[Bug middle-end/66134] New: [CHKP] ICE: Unable to coalesce ssa_names 18 and 17 which are marked as MUST COALESCE

[ienkovich at gcc dot gnu.org]

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

Bug ID: 66134
   Summary: [CHKP] ICE: Unable to coalesce ssa_names 18 and 17
which are marked as MUST COALESCE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35536&action=edit
reproducer

>gcc -O2 -fcheck-pointer-bounds -mmpx -fno-tree-ccp test.c -c

Unable to coalesce ssa_names 18 and 17 which are marked as MUST COALESCE.
__bound_tmp.0_18(ab) and  __bound_tmp.0_17(ab)
LCK-2257.c: In function 'test.chkp':
LCK-2257.c:7:6: internal compiler error: SSA corruption
 void test (int *p)
  ^
0xd3a93d fail_abnormal_edge_coalesce
../../gcc-5/gcc/tree-ssa-coalesce.c:927
0xd3b74c coalesce_partitions
../../gcc-5/gcc/tree-ssa-coalesce.c:1230
0xd3bd02 coalesce_ssa_name()
../../gcc-5/gcc/tree-ssa-coalesce.c:1375
0xcd82d3 remove_ssa_form
../../gcc-5/gcc/tree-outof-ssa.c:1018
0xcd8b3d rewrite_out_of_ssa(ssaexpand*)
../../gcc-5/gcc/tree-outof-ssa.c:1252
0x7b5c23 execute
../../gcc-5/gcc/cfgexpand.c:5932
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/33089] combine not combining add + test in if (a + b) > 0

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Segher Boessenkool  ---
This works fine today; closing as FIXED.

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
Created attachment 35537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35537&action=edit
non-working patch

This patch fails for:

struct Local
{
  void f();
};

Local *l;
void (Local::*ptr)();
decltype((l->*ptr)) i; // { dg-error "member function" }


/home/manuel/test1/src/gcc/testsuite/g++.dg/cpp0x/decltype31.C:11:19: error:
invalid use of non-static member function '#'offset_ref' not supported by
dump_decl#

We don't want to use %qE, but I'm not sure how to extract a declaration from an
offset_ref. 


(It would be great to make such things an ICE with enable-checking, the patch
passes bootstrap+regression tests!)

[Bug c++/66135] New: trailing return type generic lambda

[barry.revzin at gmail dot com]

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

Bug ID: 66135
   Summary: trailing return type generic lambda
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this attempt at implementing fmap for optionals in C++:

#include 
#include 

template 
auto fmap(Func f)
{
return [=](auto arg) -> boost::optional { // **
if (arg) {
return f(*arg); 
}
else {
return boost::none;
}
};
}


int main() {
auto id = fmap([](int i){ return i; });

auto res = id(boost::optional{42});
std::cout << *res << std::endl;
}

This code compiles in clang 3.6, but on gcc 5.1 issues an error on the
indicated line:

error: invalid type argument of unary '*' (have 'auto:1')

[Bug rtl-optimization/49884] get_last_value in combine ignores register mode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
Hi,

Can you reproduce this on any target in mainline GCC?  That would
help people reproduce this.

You say you have (set (reg:HI) (ashift:HI (reg:HI) (const_int 16)))
and that will set all of the reg:HI to 0, so the reg:QI will also
be 0?  You seem to expect something else though?

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #6 from Segher Boessenkool  ---
Mine.

[Bug middle-end/66127] Division by zero gets folded away

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
I think the proper solution is to mark all problematic operations with
TREE_SIDE_EFFECTS so that the side-effects are preserved when omitting
operands.

[Bug tree-optimization/66129] [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/66129] [6 Regression] FAIL: gcc.dg/vect/vect-strided-*c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed May 13 14:38:19 2015
New Revision: 223164

URL: https://gcc.gnu.org/viewcvs?rev=223164&root=gcc&view=rev
Log:
2015-05-13  Richard Biener  

PR tree-optimization/66129
* tree-vect-slp.c (vect_build_slp_tree): Make sure all ops are
commutative.
(vect_schedule_slp_instance): Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug middle-end/66127] Division by zero gets folded away

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Like a more complete variant of

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 223151)
+++ gcc/tree.c  (working copy)
@@ -4402,6 +4402,11 @@ build2_stat (enum tree_code code, tree t
   PROCESS_ARG (0);
   PROCESS_ARG (1);

+  if (code == TRUNC_DIV_EXPR
+  && (TREE_CODE (arg1) != INTEGER_CST
+ || integer_zerop (arg1)))
+side_effects = 1;
+
   TREE_SIDE_EFFECTS (t) = side_effects;
   if (code == MEM_REF)
 {

[Bug middle-end/66127] Division by zero gets folded away

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Where I get for the testcase

int z = 0;
int a = 1, 0;
  return a;

for some odd reason (1?! ... fold_ignored_results fault...)

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #14 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed May 13 15:00:50 2015
New Revision: 223165

URL: https://gcc.gnu.org/viewcvs?rev=223165&root=gcc&view=rev
Log:
[ARM] Fix PR 65955: Do not take REGNO on non-REG operand in movcond_addsi

Backport from mainline
2015-05-12  Kyrylo Tkachov  

PR target/65955
* config/arm/arm.md (movcond_addsi): Check that operands[2] is a
REG before taking its REGNO.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.md

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail|5.0 |5.1.0

--- Comment #15 from ktkachov at gcc dot gnu.org ---
Backported to GCC 5.
4.9 is next up after testing

[Bug c/66090] Wrong loop code generation with -O2 on ARM

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
I think this comes under tracking pointer provenance (DR#260) and saying 
that certain arithmetic on pointers derived by casts from integers has 
undefined behavior.

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[sje at gcc dot gnu.org]

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

--- Comment #16 from Steve Ellcey  ---
I tried Marek's patch and it fixed the build issue with glibc.  I did get a few
new errors that I think are caused by this change:

FAIL: g++.dg/warn/overflow-warn-1.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-1.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-1.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-3.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/warn/overflow-warn-4.C  -std=gnu++14 (test for excess errors)

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)

[dougmencken at gmail dot com]

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

--- Comment #7 from Douglas Mencken  ---
$ ls -l /usr/bin/ld
-rwxr-xr-x 1 root wheel 2622416 Jul 12  2008 /usr/bin/ld

$ /usr/bin/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-85.2.1
LLVM version 3.5.0

[Bug c/66066] [6 Regression] r222889 causes bogus error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
Yeah, fixing PR66127 in some way is a prerequisite for the patch to go in. 
PR66127 is being discussed in the ML, where I've posted an updated version of
the patch for this PR.

[Bug lto/66103] [6 Regression] ICE verify_type failed with LTO and "-g -O0" via dwarf2out.c's gen_type_die_with_usage

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-13
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
Fun. First of all, we should not produce debug info at compile time when doing
slim LTO.
Second issue is that we have one type were free_lang_data was run and other
where it wasn't.  I suppose I will need to make verifier tolerating this for
fat lto objects...

[Bug middle-end/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

--- Comment #8 from Kevin OConnor  ---
Thanks!  I can confirm the latest trunk performs the desired optimization.

However, this test case still isn't fully optimized:

void f2(struct s1 *ps1, uint8_t *pi8)
{
ps1->f1 = 3;
*pi8 = 8;
ps1->f1 += 2;
}

That is, an "uint8_t*" still aliases with every other type. The "struct"
optimization is more important for my usage, but it is unfortunate that
uint8_t*/int8_t* are pessimized.  (In particular, there does not appear to be
any way to declare a pointer to an 8 bit integer that doesn't alias every other
type.)

I can open a separate bugzilla entry on the above.

[Bug ipa/65873] [5 Regression] Failure to inline always_inline memcpy

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[5/6 Regression] Failure to |[5 Regression] Failure to
   |inline always_inline memcpy |inline always_inline memcpy

--- Comment #9 from Jan Hubicka  ---
With the workaround it is no longer 6 regression, still an ugly bug.

[Bug target/66047] [5 Regression] vlc compilation failure with target attribute

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[5/6 Regression] vlc|[5 Regression] vlc
   |compilation failure with|compilation failure with
   |target attribute|target attribute

--- Comment #3 from Jan Hubicka  ---
I managed to get wrong PR marker, but partly fixed on mainline so far by
r223111

https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01230.html

[Bug c/65892] gcc fails to implement N685 aliasing of union members

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Thanks (again) for your comments, Joseph.  I had a chance to discuss this issue
with Clark Nelson last week.  Clark has worked on improving the aliasing parts
of the C specification in the past, for example in N1520
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1520.htm).  He agreed that
like the issues pointed out in N1520, this is also an outstanding problem that
would be worth for WG14 to revisit and fix.  We also agreed to work together on
a revised paper for the next WG14 meeting in October 2015.

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[tromey at gcc dot gnu.org]

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

--- Comment #3 from Tom Tromey  ---
(In reply to Manuel López-Ibáñez from comment #1)
> Confirmed. A small testcase would help. Perhaps it would be even clearer if
> it said something like: "non-static member function can be used only as the
> operand for the function call operator()"

Here's something reasonably close to my real-life case:

struct X {
  X(void *);
  void m();
};

struct Y : public X{
  Y(void*a, void *b) : X(m), mb(b) { }
  void *mb;
};


A bit wordy perhaps.  But you can see how the error is unclear (partly
due to that other bug):

pokyo. g++ --syntax-only r.cc
r.cc: In constructor ‘Y::Y(void*, void*)’:
r.cc:7:34: error: invalid use of non-static member function
   Y(void*a, void *b) : X(m), mb(b) { }
  ^

It's even worse if you aren't familiar with the code - in my real-life
case, the typo was meant to be one of the argument names, but actually
named a method of a superclass that was in some other file...

[Bug middle-end/66133] Wrong-code with noreturn #pragma omp task body

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 13 16:59:20 2015
New Revision: 223171

URL: https://gcc.gnu.org/viewcvs?rev=223171&root=gcc&view=rev
Log:
PR middle-end/66133
* omp-low.c (expand_omp_taskreg): For GIMPLE_OMP_TASK expansion,
make sure it is never noreturn, even when the task body does not
return.
(lower_omp_taskreg): For GIMPLE_OMP_TASK, emit GIMPLE_OMP_CONTINUE
right before GIMPLE_OMP_RETURN.
(make_gimple_omp_edges): Accept GIMPLE_OMP_CONTINUE as ->cont
for GIMPLE_OMP_TASK.  For GIMPLE_OMP_RETURN corresponding to
GIMPLE_OMP_TASK add an EDGE_ABNORMAL edge from entry to exit.

* testsuite/libgomp.c/pr66133.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr66133.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Tom Tromey from comment #3)
> Here's something reasonably close to my real-life case:

For this testcase, my patch gives:

test.cc:8:34: error: invalid use of non-static member function ‘void X::m()’
   Y(void*a, void *b) : X(m), mb(b) { }
  ^

Of course, the location is bug 61940, which seems a bit harder to fix.

[Bug fortran/66128] ICE for some intrinsics with zero sized array parameter

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-13
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Confirmed.

I glance at the simplification code suggests that gfortran
is not considering the possibility of zero-sized constant
arrays.  Not sure how to fix this one.

[Bug target/66047] [5 Regression] vlc compilation failure with target attribute

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jan Hubicka from comment #3)
> I managed to get wrong PR marker, but partly fixed on mainline so far by
> r223111
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01230.html

You can do:

svn propedit 'svn:log' -r223111 --revprop

to amend it. This is good for the future when someone checks the svn logs, and
it will trigger a message here.

[Bug target/66047] [5 Regression] vlc compilation failure with target attribute

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
Author: manu
Revision: 223111
Modified property: svn:log

Modified: svn:log at Wed May 13 17:42:41 2015
--
--- svn:log (original)
+++ svn:log Wed May 13 17:42:41 2015
@@ -1,5 +1,5 @@

-   PR target/pr66047.c
+   PR target/66047
* i386.c (ix86_function_sseregparm): Only return -1 if local function
with implied regparm is called from -mno-sse function.
(init_cumulative_args): Output error if ix86_function_sseregparm

[Bug target/66136] New: AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD

[emaste at freebsd dot org]

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

Bug ID: 66136
   Summary: AArch64 geniterators.sh relies on GNU sed syntax,
causing build failure on FreeBSD
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emaste at freebsd dot org
  Target Milestone: ---

Attempting to build an AArch64 target on FreeBSD fails with:

In file included from ../../gcc/config/aarch64/aarch64-builtins.c:316:
./aarch64-builtin-iterators.h:5:1: warning: extra ';' outside of a function is
a C++11 extension [-Wc++11-extra-semi]
./aarch64-builtin-iterators.h:5:4: error: unknown type name 'Machine'
./aarch64-builtin-iterators.h:5:22: error: expected ';' after top level
declarator
./aarch64-builtin-iterators.h:5:48: warning: extra ';' outside of a function is
a C++11 extension [-Wc++11-extra-semi]
./aarch64-builtin-iterators.h:5:50: error: unknown type name 'Copyrigh'
./aarch64-builtin-iterators.h:5:62: error: expected ';' after top level
declarator
...


and aarch64-builtin-iterators.h looks like:
feynman% head gcc/aarch64-builtin-iterators.h 
/* -*- buffer-read-only: t -*- */
/* Generated automatically by geniterators.sh from iterators.md.  */
#ifndef GCC_AARCH64_ITERATORS_H
#define GCC_AARCH64_ITERATORS_H
;; Machine descripion for AArch64 archiecure. ;; Copyrigh (C) 2009-2015 Free
Sofware Foundaion, Inc. ;; Conribued by ARM Ld. ;; ;; This file is par of GCC.
;; ;; GCC is free sofware; you can redisribue i and/or modify i ;; under he
erms of he GNU General Public License as published by ;; he Free Sofware
Foundaion; eiher version 3, or (a your opion) ;; any laer version. ;; ;; GCC is
disribued in he hope ha i will be useful, bu ;; WITHOUT ANY WARRANTY; wihou
even he implied warrany of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See he GNU ;; General Public License for more deails. ;; ;; You should
have received a copy of he GNU General Public License ;; along wih GCC; see he
file COPYING3. If no see ;; . ;;
--- ;;
...

To get past this locally for now I've s/sed/gsed/ in geniterators.sh.

I think we'll want to either change the expressions to work with other sed
implementations, or require GNU sed.

[Bug target/66137] New: [4.9/5 Regression] ICE with -ffixed-ebp

[jakub at gcc dot gnu.org]

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

Bug ID: 66137
   Summary: [4.9/5 Regression] ICE with -ffixed-ebp
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

void
foo (char *x, char *y, char *z, int a)
{
  int i;
  for (i = a; i > 0; i--)
*x++ = *y++ = *z++;
}

ICEs when compiled with -mno-accumulate-outgoing-args -mavx -O3 -ffixed-ebp
starting with r203171 or when compiled with -mavx -O3 -ffixed-ebp starting with
r206947.

[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-13
   Target Milestone|--- |4.9.3
Summary|[4.9/5 Regression] ICE with |[4.9/5/6 Regression] ICE
   |-ffixed-ebp |with -ffixed-ebp
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I bet rbp is needed for dynamic stack realignment, wonder if we just shouldn't
error out in such cases and tell users it is simply bad idea to use -ffixed-ebp
in that case.

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD

[emaste at freebsd dot org]

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

--- Comment #1 from Ed Maste  ---
It appears this comes from \n newlines in the replacement pattern - I can
partially fix it by using an expression like:

sed 's/(define_mode_iterator \([A-Za-z0-9_]*\) \([]\[A-Z0-9 \t]*\)/\   
#define BUILTIN_\1(T, N, MAP) \\ \2\
/g' \

that is, putting literal escaped newlines inside the single-quoted sed
expression. However, since we're already using awk at the end of the pipeline
anyway, the whole thing ought to just be implemented in awk.

[Bug rtl-optimization/30967] Extra sign/zero extend with word comparison result

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Wed May 13 19:14:07 2015
New Revision: 223174

URL: https://gcc.gnu.org/viewcvs?rev=223174&root=gcc&view=rev
Log:
PR rtl-optimization/30967
* config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
destination mode for the cost of scc patterns.

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

[Bug go/66138] New: json decoder Decode function fails for some structure return values

[boger at us dot ibm.com]

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

Bug ID: 66138
   Summary: json decoder Decode function fails for some structure
return values
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: boger at us dot ibm.com
CC: cmang at google dot com
  Target Milestone: ---
  Host: ppc64le, ppc64, x86_64
Target: ppc64le, ppc64, x86_64

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

I'm attaching a testcase that fails when built with gccgo on ppc64le and x86_64
from the gcc5 branch.  The test also fails using gccgo built from gcc trunk on
ppc64le.  The same testcase works if compiled with gc for ppc64le and x86_64.

The problem occurs when creating a json decoder.  The difference in the cases
that pass and fail is the format of the structure being passed to the Decode
function to hold the return value.  The calls to DecodeContainerConfig2
demonstrate structures that work.  The calls to DecodeContainerConfig use
structures that fail with gccgo.

Incorrect output looks like this:

./resconf
HC  &{1000 []}
CONFIG  &{host with memory at top level}
HC  &{1000 [/tmp:/tmp]}
CONFIG  &{host with memory at top level and a hostconfig}
HC  &{1000 [/tmp:/tmp]}
CONFIG  &{host with memory inside hostconfig}


ORIGINAL CODE CAUSE
CONFIG  &{host with memory at top level}
HC  &{0 []}
CONFIG  &{host with memory at top level and a hostconfig}
HC  &{0 []}
CONFIG  &{host with memory inside hostconfig}
HC  &{0 []}

Correct output:

./resconf
HC  &{1000 []}
CONFIG  &{host with memory at top level}
HC  &{1000 [/tmp:/tmp]}
CONFIG  &{host with memory at top level and a hostconfig}
HC  &{1000 [/tmp:/tmp]}
CONFIG  &{host with memory inside hostconfig}


ORIGINAL CODE CAUSE
CONFIG  &{host with memory at top level}
HC  &{1000 []}
CONFIG  &{host with memory at top level and a hostconfig}
HC  &{1000 [/tmp:/tmp]}
CONFIG  &{host with memory inside hostconfig}
HC  &{1000 [/tmp:/tmp]}

[Bug rtl-optimization/30967] Extra sign/zero extend with word comparison result

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed on trunk.  No backport planned.

[Bug c++/66139] New: destructor not called for members of partially constructed anonymous struct/array

[f.heckenb...@fh-soft.de]

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

Bug ID: 66139
   Summary: destructor not called for members of partially
constructed anonymous struct/array
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

The attached test program tries to construct various structures
consisting of two members of some type a, where construction of the
first one succeeds and the second one throws, and checks whether the
destructor of the first one was called before the exception is
caught.

Since the first member was constructed successfully, I'd expect its
destructor to be called. Granted, I don't know the exact standard
wording, but my general idea is that once a constructor call
succeeds, an object starts to exist, thus it must at some point
cease to exist, and then its destructor must be called. clang 3.5.0
and visual c++ (according to http://webcompiler.cloudapp.net/,
without the GCC extension "(a[2]) { ... }") do call the destructor
every time.

The g++ output is:

destructor called
destructor not called
destructor called
destructor not called
destructor not called
destructor not called

So with a named struct/array variable, the destructor gets called,
with anonymous ones it doesn't.

Even with a named initializer_list it doesn't, but I suppose that's
because the compiler first constructs an anonymous array (and then
would construct the initializer_list if it got there).

#include 

int c, d;

struct a
{
  a (int i) { if (i) throw i; c++; }
  ~a () { d++; }
};

void check (void (*f) ())
{
  try
  {
c = d = 0;
f ();
  }
  catch (int)
  {
std::cerr << (c != 1 ? "constructor not completed exactly once\n" :
  d == 0 ? "destructor not called\n" :
  d == 1 ? "destructor called\n" :
   "destructor called more than once\n");
return;
  }
  std::cerr << "exception not thrown\n";
}

int main ()
{
  struct s { a x, y; };
  check ([] { s t { 0, 1 }; });
  check ([] { s { 0, 1 }; });
  check ([] { a t[2] { 0, 1 }; });
  check ([] { (a[2]) { 0, 1 }; });
  check ([] { std::initializer_list  t { 0, 1 }; });
  check ([] { std::initializer_list  { 0, 1 }; });
}

[Bug c++/66092] [c++-concepts] Concept can't check variadic template arguments

[yingpo.liao at gmail dot com]

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

--- Comment #1 from Ying-Po Liao  ---
Here's another implementation, which results in the same consequence.

template 
  struct Checker
  {
constexpr static decltype(auto) check( std::true_type )
{ return std::integral_constant(); }

constexpr static decltype(auto) check( std::false_type )
{ return std::integral_constant::value>(); }

constexpr static bool value = decltype( 
  check( std::integral_constant() ) 
)::value;
  };

template 
  concept bool Same()
  {
return Checker::value;
  }

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[lopresti at gmail dot com]

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

Patrick J. LoPresti  changed:

   What|Removed |Added

 CC||lopresti at gmail dot com

--- Comment #10 from Patrick J. LoPresti  ---
Worth noting, perhaps, that the C++ standard does _not_ require O(n) worst-case
behavior for nth_element. The exact wording (C++11 section 25.4.2
[alg.nth.element] paragraph (3)) says:

Complexity: Linear on average.

It is not obvious (to me) what distribution the "on average" refers to. All
permutations of input with equal probability, I suppose (?)

Anyway, just because GCC falls back to an O(N log N) algorithm under some
circumstances does not necessarily mean it violates the C++ specification, as
long as that fallback only happens in log N of the cases or thereabouts.

Not that I am up for actually performing this complexity analysis.

[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Possible path here:

https://gcc.gnu.org/ml/fortran/2015-05/msg00071.html