[Bug go/64005] make check FAIL: sync

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Uroš Bizjak  ---
This failure is fixed (or is hidden) by the update to Go 1.4 [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01132.html

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

[dvyukov at google dot com]

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

--- Comment #5 from Dmitry Vyukov  ---
I suspect that configure and Makefiles are gcc-specific, that is needs to be
submitted to gcc diredctly.
And for tsan_rtl.h we have a change in flight that does essentially the same
(for mips64 support):
http://reviews.llvm.org/D6291
I've asked the author to disable HACKY_CALL for everything except __x86_64__.
So it seems it can be a pure gcc change.

[Bug sanitizer/63850] Building TSAN for Aarch64 results in assembler Error

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #4 from vekumar at gcc dot gnu.org ---

We did some changes in Makefile and configure under libsantizers to make it
build for Aarch64.

As clyon said local experiments are done in GCC tree. Just capturing the
changes here. 

Ref:
https://git.linaro.org/toolchain/gcc.git/commit/07178f9e98be4fc1efad5c5d7c4fed7627c17e1f

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #13 from Joost VandeVondele  
---
(In reply to Jerry DeLisle from comment #12)
> (In reply to Joost VandeVondele from comment #11)
> 
> See patch here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01616.html

Thanks! One minor nit for the testcase,

inquire (unit=i, exist=l, iostat=i)

I guess this kind of aliasing of i is strictly speaking not OK?

[Bug ipa/64664] [5 Regression] ICE: tree check: expected function_decl, have in opts_for_fn, at tree.h:4706

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-19
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Looking at the patches the culprit is definetely r219823.

[Bug ipa/64664] New: [5 Regression] ICE: tree check: expected function_decl, have in opts_for_fn, at tree.h:4706

[trippels at gcc dot gnu.org]

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

Bug ID: 64664
   Summary: [5 Regression] ICE: tree check: expected
function_decl, have  in
opts_for_fn, at tree.h:4706
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org

I guess either r219822 or r219823 caused the following Firefox build error:

/home/trippels/gcc_test/usr/local/bin/c++ -fPIC -Wall -Wempty-body
-Woverloaded-virtual -Wsign-compare -Wwrite-strings -Werror=endif-labels
-Werror=int-to-pointer-cast -Werror=missing-braces -Werror=pointer-arith
-Werror=return-type -Werror=sequence-point -Werror=unused-label
-Werror=trigraphs -Werror=type-limits -Wno-invalid-offsetof -Wcast-align
-flto=80 --param lto-partitions=80 -mcpu=power8 -ffunction-sections
-fdata-sections -fno-exceptions -fno-strict-aliasing -frtti -fno-exceptions
-fno-math-errno -std=gnu++0x -pthread -pipe -UDEBUG -DNDEBUG -O3
-DU_STATIC_IMPLEMENTATION -fvisibility=hidden -W -Wall -pedantic
-Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-unused
-Wno-unused-parameter   -lpthread
-Wl,--hash-style=gnu,--as-needed,--gc-sections,--icf=all -Wl,-z,noexecstack
-Wl,-z,text -Wl,--build-id -Wl,--gc-sections  -o ../../bin/makeconv makeconv.o
ucnvstat.o genmbcs.o gencnvex.o -L../../lib -licutu -L../../lib -licui18n
-L../../lib -licuuc -L../../stubdata -licudata -lpthread -ldl -lm
lto1: internal compiler error: tree check: expected function_decl, have
 in opts_for_fn, at tree.h:4706
0x109fcf23 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9290
0x10164e17 tree_check(tree_node const*, char const*, int, char const*,
tree_code)
../../gcc/gcc/tree.h:3091
0x10164e17 opts_for_fn
../../gcc/gcc/tree.h:4706
0x10d90b33 opts_for_fn
../../gcc/gcc/tree.h:2846
0x10d90b33 ipa_icf::sem_item_optimizer::filter_removed_items()
../../gcc/gcc/ipa-icf.c:1656
0x10d921bf ipa_icf::sem_item_optimizer::execute()
../../gcc/gcc/ipa-icf.c:1703
0x10d930a3 ipa_icf_driver
../../gcc/gcc/ipa-icf.c:2460
0x10d930a3 ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/gcc/ipa-icf.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/c++ returned 1
exit status

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to Joost VandeVondele from comment #11)

See patch here:

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01616.html

[Bug rtl-optimization/64532] [4.9, 5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[pangbw at gmail dot com]

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

--- Comment #6 from baoshan  ---
After several days study to the code, I turn to feel the code is wrong. It
seems we should use "=t" instead of "=w" for 'y' because single float register
is expected here for "vcvt.f32.s32". From the document, "w" just means  VFP
floating-point register  but not distinguishing single, double or quad float
register:
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints

The constraint letter 't' is not documented in the GCC doc, this is a issue.

[Bug c/64663] New: ICE at -O1 and above with -g enabled on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 64663
   Summary: ICE at -O1 and above with -g enabled on
x86_64-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above with -g enabled on x86_64-linux-gnu in both 32-bit and 64-bit
modes.

The ICE also affects all earlier versions of GCC since 4.6. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150118 (experimental) [trunk revision 219826] (GCC) 

$ 
$ gcc-trunk -O0 -g -c small.c
$ gcc-trunk -O1 -c small.c
$ 
$ gcc-trunk -O1 -g -c small.c
small.c: In function ‘fn1’:
small.c:13:1: internal compiler error: Segmentation fault
 }
 ^
0xa9f6af crash_signal
../../gcc-trunk/gcc/toplev.c:381
0x736a40 decl_piece_bitsize
../../gcc-trunk/gcc/dwarf2out.c:5072
0x766c47 dw_sra_loc_expr
../../gcc-trunk/gcc/dwarf2out.c:13943
0x7673e0 dw_loc_list
../../gcc-trunk/gcc/dwarf2out.c:14118
0x7673e0 loc_list_from_tree
../../gcc-trunk/gcc/dwarf2out.c:14562
0x76c5c3 add_location_or_const_value_attribute
../../gcc-trunk/gcc/dwarf2out.c:16070
0x753250 gen_variable_die
../../gcc-trunk/gcc/dwarf2out.c:19240
0x754ef9 gen_decl_die
../../gcc-trunk/gcc/dwarf2out.c:20969
0x7566a4 process_scope_var
../../gcc-trunk/gcc/dwarf2out.c:20484
0x756877 decls_for_scope
../../gcc-trunk/gcc/dwarf2out.c:20509
0x756f6a gen_subprogram_die
../../gcc-trunk/gcc/dwarf2out.c:18832
0x754f69 gen_decl_die
../../gcc-trunk/gcc/dwarf2out.c:20902
0x755f9c dwarf2out_decl
../../gcc-trunk/gcc/dwarf2out.c:21335
0x75636e dwarf2out_function_decl
../../gcc-trunk/gcc/dwarf2out.c:21343
0x7c2dd4 rest_of_handle_final
../../gcc-trunk/gcc/final.c:4521
0x7c2dd4 execute
../../gcc-trunk/gcc/final.c:4563
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


int a, b;

void
fn1 ()
{
  int c[9] = { 0 };
  for (;;)
{
  a = (int) 3655990292 % 9;
  if (b && c[a])
c[a] = 0;
}
}

[Bug debug/57664] [4.8/4.9/5 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda

[tbsaunde at gcc dot gnu.org]

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

tbsaunde at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tbsaunde at gcc dot gnu.org

--- Comment #6 from tbsaunde at gcc dot gnu.org ---
seems to work now? maybe fixed by r209812?

[Bug rtl-optimization/64537] Aarch64 redundant sxth instruction gets generated

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
Is this sort of multiple-use potential candidate for ree pass? Haven't looked
ree in detail yet.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[howarth at bromo dot med.uc.edu]

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

--- Comment #13 from howarth at bromo dot med.uc.edu ---
Created attachment 34480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34480&action=edit
proposed fix with aix support added

[Bug c++/64644] "warning: anonymous union with no members" should be an error with -pedantic-errors

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Harald van Dijk from comment #2)
> A question, though: I see that like many other existing warnings, this
> doesn't handle -Werror=pedantic. Is that something that should be addressed
> as well, or is that something that should at some later point be handled for
> all relevant warnings at once?

From: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

-pedantic-errors
Give an error whenever the base standard (see -Wpedantic) requires a
diagnostic, in some cases where there is undefined behavior at compile-time and
in some other cases that do not prevent compilation of programs that are valid
according to the standard. This is not equivalent to -Werror=pedantic, since
there are errors enabled by this option and not enabled by the latter and vice
versa.

From: https://gcc.gnu.org/wiki/DiagnosticsGuidelines

pedwarn is for code that is accepted by GCC but it should be rejected or
diagnosed according to the current standard, or it conflicts with the standard
(either the default or the one selected by -std=). Most pedwarns are controlled
by -Wpedantic, a few are controlled by options that are enabled by -Wpedantic
and others are enabled by default. That is, although -Wpedantic is only used
for pedwarns, the choice between using pedwarn or warning is independent of
-Wpedantic and only depends on the current -std= value. 

In my ideal world, -pedantic-errors would be a deprecated (but forever kept for
backwards compatibility) alias of some -Werror=X, where X is either pedantic or
a new -W option. However, the difference between pedwarn(), -Wpedantic and
-pedantic-errors is not very straightforward. You can try to follow the
discussion here: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01799.html and
if you manage to make some sense out of it and come up with a course of action
(which option to add? what should it enable? what should be its relation with
Wpedantic and -pedantic-errors?) that convinces Joseph Myers, please add it to
PR53075 and I will eventually implement it.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[howarth at bromo dot med.uc.edu]

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

--- Comment #12 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #11)
I tried another bootstrap with the addition of --enable-lto (most of the
buildbots seem to just use the lto language for that) and it had no impact on
my test results. I guess this variation reflects some obscure difference
between bootstrapping from the FSF gcc compilers and the system clang
compilers.

[Bug c/53075] -Werror=pedantic should be equivalent to -pedantic-errors

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  ---
More discussion in the topic:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01799.html

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[joakim.tjernlund at transmode dot se]

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

--- Comment #24 from joakim.tjernlund at transmode dot se  ---
(In reply to Segher Boessenkool from comment #23)
> Do you know what addcc does?  PowerPC does not have any instruction

No, just guessing :) To me it was generic way to express add with carry

> that behaves like it at all.  So it would have to expand to a big
> fat sequence of instructions, that then hopefully are optimised to
> something sane later.  Instead, the current code expands to something
> sane immediately.

I was hoping that this 
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 0,0,3
mr 3,0
could be this instead, once you had notion for carry in gcc for ppc:
addc 3,3,4
addze 3,3

the optimized loop would be an extra bonus

[Bug target/64662] New: [SH] QImode/HImode atomics should return sign extended SImode values

[olegendo at gcc dot gnu.org]

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

Bug ID: 64662
   Summary: [SH] QImode/HImode atomics should return sign extended
SImode values
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

Currently, QImode/HImode atomic insns return the values as such, although the
memory loads actually do a sign extension.  They should return sign extended
SImode values instead, so that it's easier to eliminate redundant sign/zero
extensions around atomic insns.

Example:

int test4 (volatile char* mem)
{
  return __atomic_fetch_add (mem, 1, __ATOMIC_ACQ_REL);
}

compiled with -O2 -m4 -matomic-model=soft-gusa:

mov #1,r3

mova1f,r0  ! atomic_fetch_addqi_soft_gusa  [length = 18]
.align 2
mov r15,r1
mov #(0f-1f),r15
0:  mov.b   @r4,r2<<< sign extending load of previous value
mov r2,r7
add r3,r7
mov.b   r7,@r4
1:  mov r1,r15
rts
exts.b  r2,r0 <<< redundant sign extension

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  ---
libgomp-plugin-host_nonshm.so.1 which is inserted into
libgomp-plugin-host_nonshm.a (Traditional AIX shared library filenames do not
have version numbers.)

[Bug target/64661] New: [SH] Allow @(disp,reg) address mode for atomics

[olegendo at gcc dot gnu.org]

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

Bug ID: 64661
   Summary: [SH] Allow @(disp,reg) address mode for atomics
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

Atomics that do not use the 'movli.l' and 'movco.l' insns should be able to use
the '@(disp,reg)' address mode for SImode, since those don't have a R0 operand
restriction.

For example:

void test4 (int* mem)
{
  __atomic_add_fetch (mem + 3, 1, __ATOMIC_ACQ_REL);
}

now compiled with -O2 -m4 -ml -matomic-model=soft-gusa:

mov #1,r2
add #12,r4

mova1f,r0
mov r15,r1
.align 2
mov #(0f-1f),r15
0:  mov.l   @r4,r3
add r2,r3
mov.l   r3,@r4
1:  mov r1,r15

should be:
mova1f,r0
mov r15,r1
.align 2
mov #(0f-1f),r15
0:  mov.l   @(12,r4),r2   // use @(disp,reg)
add #1,r2 // PR 64659
mov.l   r2,@(12,r4)   // use @(disp,reg)
1:  mov r1,r15


The 'atomic__fetch_soft_imask' and
'atomic_nand_fetch_soft_imask' insns could also use QImode and HImode
@(disp,reg) address modes, since the other operand is already R0.

[Bug c++/64644] "warning: anonymous union with no members" should be an error with -pedantic-errors

[harald at gigawatt dot nl]

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

--- Comment #2 from Harald van Dijk  ---
Yep, thanks, testing that on 4.9.2 seems to give the right results. I see it
covered by existing tests in at least
gcc/testsuite/g++.old-deja/g++.law/union4.C and
gcc/testsuite/g++.old-deja/g++.law/union4.C. I'll re-test with GCC 5 soonish
(later in the week, probably), change dg-warning to dg-error where appropriate,
and check if there's already a test to make sure it remains a warning without
-pedantic-errors.

A question, though: I see that like many other existing warnings, this doesn't
handle -Werror=pedantic. Is that something that should be addressed as well, or
is that something that should at some later point be handled for all relevant
warnings at once?

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[segher at gcc dot gnu.org]

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

--- Comment #23 from Segher Boessenkool  ---
Do you know what addcc does?  PowerPC does not have any instruction
that behaves like it at all.  So it would have to expand to a big
fat sequence of instructions, that then hopefully are optimised to
something sane later.  Instead, the current code expands to something
sane immediately.

The problem for this testcase (as for all other similar "manual carry"
cases) is that we need to replace the carry in our original patterns
with (1 - carry).  There is no good way to do that in combine, we would
need to combine three insns, the first two of which are a parallel.

[Bug lto/64374] [5.0 regression] LTO ICE in extract_insn, at recog.c:2327

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
This is ugly issue indeed, I will look more into it tomorrow.
Optimally of course we should be able to handle -fPIC per symbol basis, but
that is hard to do. I guess having it handled via ix86_option_override_internal
is not a bad temporary plan.

Out of the options lto-wrapper handles, I think the following can be now
dropped:
case OPT_fexceptions:
case OPT_fnon_call_exceptions:
case OPT_fshort_double:
case OPT_fmath_errno:
case OPT_fsigned_zeros:
case OPT_ftrapping_math:
case OPT_fwrapv:
case OPT_ftrapv:
case OPT_fstrict_overflow:
case OPT_foffload_abi_:
case OPT_O:
case OPT_Ofast:
case OPT_Og:
case OPT_Os:

But that can probalby wait for stage1, they are harmless (I would not be
affraid to drop them now)

I think I missed the following in my weekend's common.opt update. It should be
Optimization.
case OPT_fpcc_struct_return:
case OPT_ffp_contract_:

I however think there are couple other options that may be wroth merging, like
-fdata-sections that does not go via optimization machinery.


Honza

[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
Good, now it reproduces.  The problem is that inliner removes the alias target
and it leaves the alias itself to be removed by remove_unreachable_nodes.  It
however manages to crash ealrier looking if the alias shall be inlined as
called once in somewhat convoluted test whether symbol is an alias.

Index: ipa-inline.c
===
--- ipa-inline.c(revision 219826)
+++ ipa-inline.c(working copy)
@@ -866,7 +866,8 @@ want_inline_function_to_all_callers_p (s
 {
   bool has_hot_call = false;

-  if (node->ultimate_alias_target () != node)
+  /* Aliases gets inlined along with the function they alias.  */
+  if (node->alias)
 return false;
   /* Already inlined?  */
   if (node->global.inlined_to)

[Bug target/64659] [SH] Immedate values not used for atomic ops

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
The other issue is that atomic add insns for models other than 'hard-llcs' do
not utilize the 'add #imm,Rn' insn at all, because those insns allow
'register_operand' only.

[Bug target/64659] [SH] Immedate values not used for atomic ops

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 Ever confirmed|0   |1

--- Comment #1 from Oleg Endo  ---
The predicates must include "const_int" in match_code, otherwise the generated
predicate code will check the operand mode and will reject const_int since they
don't have a mode.

The following fixes the issue:

Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 219823)
+++ gcc/config/sh/predicates.md(working copy)
@@ -1139,18 +1139,20 @@
 ;; values.  Using these predicates avoids the usage of 'force_reg' in the
 ;; expanders.
 (define_predicate "atomic_arith_operand"
-  (ior (match_code "subreg,reg")
-   (and (match_test "satisfies_constraint_I08 (op)")
-(match_test "mode != QImode")
-(match_test "mode != HImode")
-(match_test "TARGET_SH4A"
+  (and (match_code "subreg,reg,const_int")
+   (ior (match_operand 0 "arith_reg_operand")
+(and (match_test "satisfies_constraint_I08 (op)")
+ (match_test "mode != QImode")
+ (match_test "mode != HImode")
+ (match_test "TARGET_SH4A")

 (define_predicate "atomic_logical_operand"
-  (ior (match_code "subreg,reg")
-   (and (match_test "satisfies_constraint_K08 (op)")
-(match_test "mode != QImode")
-(match_test "mode != HImode")
-(match_test "TARGET_SH4A"
+  (and (match_code "subreg,reg,const_int")
+   (ior (match_operand 0 "arith_reg_operand")
+(and (match_test "satisfies_constraint_K08 (op)")
+ (match_test "mode != QImode")
+ (match_test "mode != HImode")
+ (match_test "TARGET_SH4A")

 ;; A predicate describing the T bit register in any form.
 (define_predicate "t_reg_operand"

[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
Created attachment 34479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34479&action=edit
unreduced testcase

Unreduced testcase is attached. Crashes both on ppc64 and x86_64.

 % g++ -w -c -O3 -std=c++11 recursive_variant_test.ii

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
For some reason you have less expected passes than me: yours

=== libgomp Summary ===

# of expected passes11430
# of unsupported tests562

mine

=== libgomp Summary ===

# of expected passes12310
# of unexpected failures216
# of unsupported tests588

my config is

../work/configure --prefix=/opt/gcc/gcc4.10w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto
--with-gmp=/opt/mp-new --with-system-zlib --with-isl=/opt/mp-new --enable-lto
--enable-plugin --with-arch=corei7 --with-cpu=corei7

on a MacBook Pro (Retina, 15-inch, Early 2013) processor 2,8 GHz Intel Core i7,
GPU NVIDIA GeForce GT 650M.

[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Jan 18 22:01:29 2015
New Revision: 219827

URL: https://gcc.gnu.org/viewcvs?rev=219827&root=gcc&view=rev
Log:
2015-01-18  Andre Vehreschild  
Janus Weil 

PR fortran/60255
* class.c (gfc_get_len_component): New.
(gfc_build_class_symbol): Add _len component to unlimited
polymorphic entities.
(find_intrinsic_vtab): Removed emitting of error message.
* gfortran.h: Added prototype for gfc_get_len_component.
* simplify.c (gfc_simplify_len): Use _len component where
available.
* trans-expr.c (gfc_class_len_get): New.
(gfc_conv_intrinsic_to_class): Add handling for deferred
character arrays.
(gfc_conv_structure): Treat _len component correctly.
(gfc_conv_expr): Prevent bind_c handling when not required.
(gfc_trans_pointer_assignment): Propagate _len component.
* trans-stmt.c (class_has_len_component): New.
(trans_associate_var): _len component treatment for associate
context.
(gfc_trans_allocate): Same as for trans_associate_var()
* trans.h: Added prototype for gfc_class_len_get.

2015-01-18  Andre Vehreschild  

PR fortran/60255
* gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
* gfortran.dg/unlimited_polymorphic_20.f03: New test.

2015-01-18  Paul Thomas  

PR fortran/64578
* gfortran.dg/unlimited_polymorphic_21.f90: New test

Added:
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03

[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function

[pault at gcc dot gnu.org]

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

--- Comment #16 from Paul Thomas  ---
Author: pault
Date: Sun Jan 18 22:01:29 2015
New Revision: 219827

URL: https://gcc.gnu.org/viewcvs?rev=219827&root=gcc&view=rev
Log:
2015-01-18  Andre Vehreschild  
Janus Weil 

PR fortran/60255
* class.c (gfc_get_len_component): New.
(gfc_build_class_symbol): Add _len component to unlimited
polymorphic entities.
(find_intrinsic_vtab): Removed emitting of error message.
* gfortran.h: Added prototype for gfc_get_len_component.
* simplify.c (gfc_simplify_len): Use _len component where
available.
* trans-expr.c (gfc_class_len_get): New.
(gfc_conv_intrinsic_to_class): Add handling for deferred
character arrays.
(gfc_conv_structure): Treat _len component correctly.
(gfc_conv_expr): Prevent bind_c handling when not required.
(gfc_trans_pointer_assignment): Propagate _len component.
* trans-stmt.c (class_has_len_component): New.
(trans_associate_var): _len component treatment for associate
context.
(gfc_trans_allocate): Same as for trans_associate_var()
* trans.h: Added prototype for gfc_class_len_get.

2015-01-18  Andre Vehreschild  

PR fortran/60255
* gfortran.dg/unlimited_polymorphic_2.f03: Removed error.
* gfortran.dg/unlimited_polymorphic_20.f03: New test.

2015-01-18  Paul Thomas  

PR fortran/64578
* gfortran.dg/unlimited_polymorphic_21.f90: New test

Added:
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03

[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
I don't seem to be able to make sense of Ilya's logic in the probability
calculation (incrementing the count with bb->count seem wrong). 
Will try to update his patch today.

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[joakim.tjernlund at transmode dot se]

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

--- Comment #22 from joakim.tjernlund at transmode dot se  ---
(In reply to Segher Boessenkool from comment #21)
> Mainine (will be GCC 5 in a few months).
> 
> There is no addcc thing, that is not suitable for PowerPC.
> The big changes are in though (and they are much bigger than
> I originally thought, fwiw -- scope creep ;-) )

Nice, but why is not addcc suitable for powerpc?
I guess you mean in its current form, it needs to be adapted to
really fit ppc(so that a loop with addcc in it is optimal)?

[Bug target/64660] New: [SH] Convert atomic_fetch_ to atomic__fetch

[olegendo at gcc dot gnu.org]

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

Bug ID: 64660
   Summary: [SH] Convert atomic_fetch_ to atomic__fetch
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

Example:

void test2 (volatile int* mem)
{
  __atomic_fetch_add (mem, 1, __ATOMIC_ACQ_REL);
}

void test3 (volatile int* mem)
{
  __atomic_add_fetch (mem, 1, __ATOMIC_ACQ_REL);
}

The two functions are equivalent, since the result value of __atomic_fetch_add
is not used in test2.  In such cases the atomic insn will have an REG_UNUSED
note and the insn can be converted into the shorter __atomic_add_fetch sequence
in the split1 pass.

[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
Would be possible to upload updated testcase? The reduced one seems to work for
me on both x86-64 and ppc64.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[howarth at bromo dot med.uc.edu]

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

--- Comment #10 from howarth at bromo dot med.uc.edu ---
The test cases showing up as unsupported here are actually aborting...

% fsf-gdb ./acc_on_device-1.exe 
Program received signal SIGABRT, Aborted.
0x9b91069a in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x9b91069a in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
#1  0x91118f19 in ?? () from /usr/lib/system/libsystem_pthread.dylib
#2  0x98b16eee in abort () from /usr/lib/system/libsystem_c.dylib
#3  0x1ed0 in ?? ()
#4  0x0028dc49 in ?? () from /sw/lib/gcc5.0/lib/i386/libgomp.1.dylib
#5  0x1d9d in ?? ()
#6  0x9ae236d9 in start () from /usr/lib/system/libdyld.dylib
warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#7  0x0001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#8  0xb6bc in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#9  0x0001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)

#10 0xb80c in ?? ()
(gdb)

[Bug target/64659] New: [SH] Immedate values not used for atomic ops

[olegendo at gcc dot gnu.org]

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

Bug ID: 64659
   Summary: [SH] Immedate values not used for atomic ops
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

Compiling the following example:

void test4 (volatile int* mem)
{
  __atomic_or_fetch (mem, 1, __ATOMIC_ACQ_REL);
}

with -O2 -m4a -m{l|b} -matomic-model=soft-gusa results in:

mov#1,r1

0:  movli.l@r4,r0  ! 7  atomic_or_fetchsi_hard  [length = 8]
orr1,r0
movco.lr0,@r4
bf0b
rts
nop

For some reason, the predicates 'atomic_arith_operand' and
'atomic_logical_operand' don't allow immediate values, although they are
supposed to do so.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[howarth at bromo dot med.uc.edu]

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

--- Comment #9 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #8)

Reverting to a clean tree at r219824 and reapplying...

https://gcc.gnu.org/bugzilla/attachment.cgi?id=34469
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01479.html

I still get pristine test suite results in libgomp.

Native configuration is x86_64-apple-darwin14.1.0

=== libgomp tests ===


Running target unix/-m32

=== libgomp Summary for unix/-m32 ===

# of expected passes5715
# of unsupported tests281

Running target unix/-m64

=== libgomp Summary for unix/-m64 ===

# of expected passes5715
# of unsupported tests281

=== libgomp Summary ===

# of expected passes11430
# of unsupported tests562

Compiler version: gcc libgomp 
Platform: x86_64-apple-darwin14.1.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man
--infodir=/sw/lib/gcc5.0/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-5.0

Here, bootstrapping from the system compilers, those failing test cases show up
as unsupported...

Executing on host: /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/ -x c++
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_on_device-1.c

-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/.libs
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/../../include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/..
-march=i486 -shared-libgcc -fmessage-length=0 -fno-diagnostics-show-caret
-fdiagnostics-color=never -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0 -nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include/x86_64-apple-darwin14.1.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/testsuite/util
-fno-builtin-acc_on_device
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/../libstdc++-v3/src/.libs
 
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/../libstdc++-v3/src/.libs
-lstdc++ -lm   -m32 -o ./acc_on_device-1.exe(timeout = 300)
spawn /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/ -x c++
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_on_device-1.c
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/.libs
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/../../include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libgomp/testsuite/..
-march=i486 -shared-libgcc -fmessage-length=0 -fno-diagnostics-show-caret
-fdiagnostics-color=never -fopenacc -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0 -nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include/x86_64-apple-darwin14.1.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150118/libstdc++-v3/testsuite/util
-fno-builtin-acc_on_device
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/../libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.1.0/i386/libgomp/../libstdc++-v3/src/.libs
-lstdc++ -lm -m32 -o ./acc_on_device-1.exe^M
PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_on_device-1.c
-DACC_DEVICE_TYPE_host_non

[Bug ipa/64378] [5 Regression] ICE: in inline_call, at ipa-inline-transform.c:347 with -O3 -fno-ipa-cp

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

[Bug fortran/64654] problem of handling character arguments in parent of an 'entry' with fewer arguments at -O0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
Mainine (will be GCC 5 in a few months).

There is no addcc thing, that is not suitable for PowerPC.
The big changes are in though (and they are much bigger than
I originally thought, fwiw -- scope creep ;-) )

[Bug libstdc++/29366] atomics config for sh is weird

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Created attachment 34478
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34478&action=edit
proposed workaround patch

There hasn't been any update for PR 53579.  I'd like to propose the attached
patch as a work around until the CXXFLAGS_FOR_TARGET issues has been
figured/sorted out.
The patch works on a default sh-elf/newlib config -- it just uses the
single-thread fake atomics from libstdc++.  Kaz, could you please try the patch
on sh4-linux?

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[clyon at gcc dot gnu.org]

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

--- Comment #11 from clyon at gcc dot gnu.org ---
(In reply to David Abdurachmanov from comment #8)
> I will finish testing my patch for upstream next week. I was busy with other
> tasks.
> 
How are you going to test it?

FYI, I am now able to run the LLVM/Asan tests on a AArch64 system, and I have
noticed numerous failures. I'm currently debugging the Asan instrumentation
code which is generating memory accesses to invalid memory areas.

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||64131

--- Comment #10 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #7)
> And the reason for that is that aarch64 again changed ABI, what a stable
> port :(.
> 
> https://sourceware.org/git/?p=glibc.git;a=commit;
> h=5c40c3bab2fddaca8cfe12d75944d1fef8adf1a4

This was recorded as bug 64131.  I filed it when I updated my glibc sources and
found Asan was broken.

Note ILP32 is also broken with Asan.

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

--- Comment #10 from Adrien Guinet  ---
Well, okay, that implication didn't look that obvious. Sorry for the constant
bug reopening, it was not my intent. And thanks for the clarifications!

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 Ever confirmed|0   |1

--- Comment #9 from Jakub Jelinek  ---
I've used:
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h   
2014-11-14 00:10:33.735060963 +0100
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h   
2015-01-18 14:43:05.812763769 +0100
@@ -167,7 +167,7 @@ namespace __sanitizer {
 unsigned __seq;
 u64 __unused1;
 u64 __unused2;
-#elif defined(__mips__)
+#elif defined(__mips__) || defined(__aarch64__)
 unsigned int mode;
 unsigned short __seq;
 unsigned short __pad1;
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc   
2014-11-14 00:10:33.735060963 +0100
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc   
2015-01-18 14:47:18.901482608 +0100
@@ -1055,7 +1055,10 @@ CHECK_SIZE_AND_OFFSET(ipc_perm, uid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, gid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, cuid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, cgid);
+#if !defined(__aarch64__) || !SANITIZER_LINUX || __GNUC_PREREQ (2, 21)
+/* On aarch64 glibc 2.20 and earlier provided incorrect mode field.  */
 CHECK_SIZE_AND_OFFSET(ipc_perm, mode);
+#endif

 CHECK_TYPE_SIZE(shmid_ds);
 CHECK_SIZE_AND_OFFSET(shmid_ds, shm_perm);

to fix the #c6 issue.  That said, seems asan is totally broken at least in
Fedora 22/aarch64, but at least it builds with this
and r223925 cherry-pick.
Pretty much every test dies with
AddressSanitizer CHECK failed:
../../../../libsanitizer/asan/asan_poisoning.cc:24 "((AddrIsInMem(addr))) !=
(0)

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

--- Comment #8 from David Abdurachmanov  
---
I will finish testing my patch for upstream next week. I was busy with other
tasks.

AArch64 is young, this kind of things are bound to happen :/

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
.

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Adrien Guinet from comment #7)
> From my understanding of
> https://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html, the "aligned"
> attribute inside a structure aligns the object inside this structure, and
> nothing more, as the example says:
> 
> "You can also specify the alignment of structure fields. For example, to
> create a double-word aligned int pair, you could write:
> 
>   struct foo { int x[2] __attribute__ ((aligned (8))); };
>   
> 
> This is an alternative to creating a union with a double member that forces
> the union to be double-word aligned. "
> 
> If I create a union, there is no alignment information. Anyway, I'd be happy
> to read the official definition if it is specified somewhere!

Your understanding is wrong.  If certain field requires some alignment, then
obviously the whole structure requires that alignment too, otherwise the field
would not be aligned as requested (unless the struct is __attribute__((packed))
of course).  Just try to print __alignof__ (struct A), you'll see it is 32.
Anyway, please stop reopening, GCC bugzilla is for reporting compiler bugs, not
a place to learn C and/or the GCC extensions.  Please try gcc-help mailing
list.

[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function

[paul.richard.thomas at gmail dot com]

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

--- Comment #15 from paul.richard.thomas at gmail dot com  ---
(In reply to Dominique d'Humieres from comment #12)
> AFAICT gfortran.dg/unlimited_polymorphic_21.f90 has not yet been committed.

You are absolutely correct. I just notice it when applying Andre's patch for
PR60255 with view to committing it. I have been rushing a bit too much with
this flood of patches. "More haste, less speed", as we anglo-saxons say :-)

I'll commit it with the patch for PR60255

Thanks

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

Adrien Guinet  changed:

   What|Removed |Added

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

--- Comment #7 from Adrien Guinet  ---
>From my understanding of
https://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html, the "aligned"
attribute inside a structure aligns the object inside this structure, and
nothing more, as the example says:

"You can also specify the alignment of structure fields. For example, to create
a double-word aligned int pair, you could write:

  struct foo { int x[2] __attribute__ ((aligned (8))); };


This is an alternative to creating a union with a double member that forces the
union to be double-word aligned. "

If I create a union, there is no alignment information. Anyway, I'd be happy to
read the official definition if it is specified somewhere!

Thanks!

[Bug target/64652] [SH] ICE when using -mdiv=call-fp

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #2 from Oleg Endo  ---
Fixed.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 Ever confirmed|0   |1

--- Comment #8 from Dominique d'Humieres  ---
With the attached patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=34469
and the patch at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01479.html, I
get

Running target unix/-m64
FAIL: libgomp.oacc-fortran/asyncwait-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/asyncwait-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/asyncwait-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/asyncwait-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/asyncwait-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/asyncwait-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-4.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-4.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-5.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-5.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-6.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-6.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-7.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-7.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/collapse-8.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/collapse-8.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/data-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/data-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/data-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/data-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/data-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/data-3.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/data-4-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/data-4-2.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/data-4.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/data-4.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-fortran/pset-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (internal compiler error)
FAIL: libgomp.oacc-fortran/pset-1.f90 -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0  -g -flto  (test for excess errors)
FAIL: libgomp.oacc-f

[Bug target/64652] [SH] ICE when using -mdiv=call-fp

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
Author: olegendo
Date: Sun Jan 18 18:12:53 2015
New Revision: 219824

URL: https://gcc.gnu.org/viewcvs?rev=219824&root=gcc&view=rev
Log:
gcc/
PR target/64652
* config/sh/sh.md (udivsi3_i4, divsi3_i4): Make use of sfunc address
reg appear first in the parallel.

gcc/testsuite/
PR target/64652
* gcc.target/sh/torture/pr64652.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/torture/pr64652.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
You are wrong on this.  You've told the compiler that those arrays will be
aligned to 32 bytes, but they are not, so running the code is undefined
behavior.  malloc doesn't have a way to pass alignment requirements to it, so
there is no way it could know about the alignment requirements of struct A.

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

--- Comment #5 from Adrien Guinet  ---
Moreover, the test case runs fine without any automatic vectorisation and
crashes when it is applied, so from my point of view there is something wrong
with this optimisation!

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

Adrien Guinet  changed:

   What|Removed |Added

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

--- Comment #4 from Adrien Guinet  ---
IMHO, bug isn't resolved!

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

--- Comment #3 from Adrien Guinet  ---
I don't think this is a user error. Some attributes might be declared aligned
inside a structure, without any specifications that every instanced objects
must be themselves aligned on a specific boundary. This is espacially true with
C++ !

[Bug target/61641] [4.9/5 Regression] undefined label in jump_table_data

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #15 from John David Anglin  ---
The failure mentioned in comment #13 is gone.

[Bug c/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That is a user error.  malloc doesn't guarantee bigger alignment than alignment
of basic C types.  If you need to allocate heap memory with bigger alignments,
you need to use different allocation functions, like posix_memalign, memalign,
aligned_alloc, valloc, pvalloc or mmap.

[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
N.B. this is fixed when using the new std::__cxx11::basic_string in GCC 5

[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Hi Markus,

How often is rs6000_stack_info called there?  Are there any hotspots
in the function?

Do you have a standalone testcase?

[Bug ipa/64378] [5 Regression] ICE: in inline_call, at ipa-inline-transform.c:347 with -O3 -fno-ipa-cp

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Sun Jan 18 17:31:35 2015
New Revision: 219822

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

PR ipa/64378
* ipa-prop.c (try_make_edge_direct_virtual_call): Clear speculative
flag correctly.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Handle speculation.
* g++.dg/torture/pr64378.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr64378.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/64658] std::atomic_init() undefined

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Testcase for 4.9 (which doesn't have the fix for PR64940 that allows
std::atomic_int t o be used interchangeably with std::atomic):

#include 

int main()
{
  std::atomic a;
  atomic_init(&a, 0);
}

[Bug libstdc++/64658] std::atomic_init() undefined

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Although atomic_init doesn't need to be atomic the simplest way to implement it
is just with a relaxed store:

--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -921,11 +921,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   template
 inline void
-atomic_init(atomic<_ITp>* __a, _ITp __i) noexcept;
+atomic_init(atomic<_ITp>* __a, _ITp __i) noexcept
+{ __a->store(__i, memory_order_relaxed); }

   template
 inline void
-atomic_init(volatile atomic<_ITp>* __a, _ITp __i) noexcept;
+atomic_init(volatile atomic<_ITp>* __a, _ITp __i) noexcept
+{ __a->store(__i, memory_order_relaxed); }

   template
 inline void


A better implementation would make atomic_init friend of std::atomic so it can
set the private data member directly.

[Bug libstdc++/64658] New: std::atomic_init() undefined

[redi at gcc dot gnu.org]

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

Bug ID: 64658
   Summary: std::atomic_init() undefined
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

#include 

int main()
{
  std::atomic_int a;
  atomic_init(&a, 0);
}

$ g++ -std=c++11 at.cc
In file included from at.cc:1:0:
/home/jwakely/gcc/5/include/c++/5.0.0/atomic:924:5: warning: inline function
‘void std::atomic_init(std::atomic<_ITp>*, _ITp) [with _ITp = int]’ used but
never defined
 atomic_init(atomic<_ITp>* __a, _ITp __i) noexcept;
 ^
/tmp/ccZgPnay.o: In function `main':
/tmp/at.cc:6: undefined reference to `void
std::atomic_init(std::atomic*, int)'
collect2: error: ld returned 1 exit status

[Bug libstdc++/64657] Support iterators with overloaded operator-comma

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-18
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Created attachment 34477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34477&action=edit
Cast expressions to void when separated by comma

This patch fixes all the places I found. I'll commit it during stage1.

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[joakim.tjernlund at transmode dot se]

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

--- Comment #20 from joakim.tjernlund at transmode dot se  ---
(In reply to Segher Boessenkool from comment #19)
> Current code:
> 
> add 3,3,4
> subfc 4,4,3
> subfe 9,9,9
> subf 3,9,3
> 
> so we got rid of the useless register move.

Which gcc version?

Any progress with the bigger change(cc expander)?

[Bug libstdc++/64657] New: Support iterators with overloaded operator-comma

[redi at gcc dot gnu.org]

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

Bug ID: 64657
   Summary: Support iterators with overloaded operator-comma
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

It's not possible to use several libstdc++ algorithms with iterators that have
overloaded comma operators, due to expressions like:

  ++__beg, ++__pos;

[Bug target/64505] Powerpc compiler generates insn not found for -m32 -mpowerpc64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
So, fixed?

[Bug libstdc++/64656] [C++14] DR 2128 Absence of global functions cbegin/cend

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug libstdc++/64656] New: [C++14] DR 2128 Absence of global functions cbegin/cend

[redi at gcc dot gnu.org]

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

Bug ID: 64656
   Summary: [C++14] DR 2128 Absence of global functions
cbegin/cend
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

http://cplusplus.github.io/LWG/lwg-defects.html#2128

C++14 mode is mssing cbegin, rbegin, crbegin etc.

#include 

int main()
{
  int i[1];
  std::cbegin(i);
  std::cend(i);
  std::rbegin(i);
  std::rend(i);
  std::crbegin(i);
  std::crend(i);
}

[Bug target/43892] PowerPC suboptimal "add with carry" optimization

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
Current code:

add 3,3,4
subfc 4,4,3
subfe 9,9,9
subf 3,9,3

so we got rid of the useless register move.

[Bug c++/64655] Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

--- Comment #1 from Adrien Guinet  ---
Created attachment 34476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34476&action=edit
test case reproducing the issue

[Bug c++/64655] New: Vectorizer is always using load aligned instructions with objects with the "aligned" attribute

[adrien at guinet dot me]

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

Bug ID: 64655
   Summary: Vectorizer is always using load aligned instructions
with objects with the "aligned" attribute
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien at guinet dot me

I think there is an issue with the way gcc uses the __attribute__ information
when generating SIMD load instructions during auto vectorization.

For instance, using a structure like this one:

struct A
{
uint32_t i[N] __attribute__((aligned(32)));
uint32_t j[N] __attribute__((aligned(32)));
uint32_t r[N] __attribute__((aligned(32)));
};

with a loop like this one:

struct A *a = (struct A*) malloc(sizeof(struct A));
for (size_t i = 0; i < N; i++) {
   a->r[i] = a->i[i] + a->j[i];
}

then the vectorizer will use "load aligned" instructions. The issue is that,
even if i, j and r are aligned *inside* the A structure, nothing tells gcc that
the "a" pointer is actually correctly aligned.

You can reproduce this using the attached "test_align.c" test case, and
compiling it like this (using AVX2 for instance which needs 32-bytes
alignment):

$ gcc -O3 -march=core-avx2 test_align.c -std=c99 -o test_align

Running it on a computer supporting AVX2 will segfault. If you don't have AVX2
on your machine, you can use the excellent Intel SDE
(https://software.intel.com/en-us/articles/intel-software-development-emulator)
which will use PIN to "emulate" AVX2. Running the sample under SDE will even
tell us this:

$ sde64 -- ./test_align 
SDE ERROR:  TID: 0 executed instruction with an unaligned memory reference to
address 0x602ab0 INSTR: 0x000400550: IFORM: VMOVDQA_YMMqq_MEMqq :: vmovdqa
ymm0, ymmword ptr [rax+0x1aa0]
IMAGE:/tmp/test_align
FUNCTION: main

Indeed, if we take a look at the assembly produced, we see:

[.. init code with rand() calls .., then, without any guards checking aligned
pointers]
lea rdx, [r13+1A80h]
mov rax, r13
loc_400550:
  vmovdqa ymm0, ymmword ptr [rax+1AA0h]  <- aligned load
  vpaddd  ymm0, ymm0, ymmword ptr [rax]  <- aligned load
  add rax, 20h
  vmovdqa ymmword ptr [rax+3520h], ymm0 <- aligned store
  cmp rax, rdx
  jnz short loc_400550

If we remove the aligned attributes, ending with this structure:

struct A
{
uint32_t i[N];
uint32_t j[N];
uint32_t r[N];
}

then gcc generates guard to check for unaligned pointers, and everything runs
fine!

Note that clang uses unaligned loads even with the aligned attributes (and thus
the binary does not segfault). The disassembly from the binary produced with
clang 3.5 is this one:

mov rax, 0F960h
loc_400670: 
  vmovdqu ymm0, ymmword ptr [r14+rax*4+3510h]
  vpaddd  ymm0, ymm0, ymmword ptr [r14+rax*4+1A80h]
  vmovdqu ymmword ptr [r14+rax*4+4FA0h], ymm0
  add rax, 8
  jnz short loc_400670

Bug seen in GCC 4.8.3 and GCC 4.9.2.

Thanks for any thoughts about this!

Regards,

Adrien.

[Bug libstdc++/64646] New overloads of std::is_permutation dereference past-the-end iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.3

--- Comment #3 from Jonathan Wakely  ---
Fixed for 4.9.3 and 5.0

[Bug libstdc++/64646] New overloads of std::is_permutation dereference past-the-end iterator

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Sun Jan 18 16:31:06 2015
New Revision: 219821

URL: https://gcc.gnu.org/viewcvs?rev=219821&root=gcc&view=rev
Log:
PR libstdc++/64646
* include/bits/stl_algo.h (__is_permutation): Also test for reaching
end of the second range.
* testsuite/25_algorithms/is_permutation/64646.cc: New.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/is_permutation/64646.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h

[Bug fortran/64654] problem of handling character arguments in parent of an 'entry' with fewer arguments at -O0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Reduced testcase.

  subroutine s(n,a)
  implicit none
  integer :: n
  character(len=n) :: a
  print *, 's'
  entry s0()
  print *, 's0'
  end subroutine s

  program p
  implicit none
  call s0()
  end program p

Workaround.  Don't compile with -O0.  All other optimiziation
levels -O1, -O2, and -O3 with and without -fcheck=all compile
and run for gfortran 5.0.

[Bug libstdc++/64646] New overloads of std::is_permutation dereference past-the-end iterator

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Sun Jan 18 16:29:57 2015
New Revision: 219820

URL: https://gcc.gnu.org/viewcvs?rev=219820&root=gcc&view=rev
Log:
PR libstdc++/64646
* include/bits/stl_algo.h (__is_permutation): Also test for reaching
end of the second range.
* testsuite/25_algorithms/is_permutation/64646.cc: New.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/25_algorithms/is_permutation/64646.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/stl_algo.h

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[howarth at bromo dot med.uc.edu]

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

--- Comment #11 from howarth at bromo dot med.uc.edu ---
(In reply to David Edelsohn from comment #9)

Also, could you confirm the exact filename you are getting for the
libgomp-plugin-host_nonshm shared library on AIX (e.g, is the suffix .1.a or
.a.1? I'll update the proposed patch in PR64635 for AIX to add and use a
libgomp/config/aix/plugin-suffix.h.

[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
Committed to trunk as revision 219818. Change logs correct in 219819.

Sorry for the mess.

Paul

[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from paul.richard.thomas at gmail dot com  ---
Ignore comment 13! I screwed up the Change Logs for PR57959.

Paul

[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components

[paul.richard.thomas at gmail dot com]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
The incorrect PR numbers in the Change Logs have been corrected.

[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Sun Jan 18 15:52:49 2015
New Revision: 219818

URL: https://gcc.gnu.org/viewcvs?rev=219818&root=gcc&view=rev
Log:
2015-01-18  Paul Thomas  

PR fortran/64578
* trans-expr.c (gfc_trans_subcomponent_assign): Use a deep copy
for allocatable components, where the source is a variable.

2015-01-18  Paul Thomas  

PR fortran/64578
* gfortran.dg/block_13.f08: New test

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

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

[howarth at bromo dot med.uc.edu]

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

--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to David Edelsohn from comment #9)
> Locally reverting the creation of offload_table may avoid the reference to
> the undefined symbol as a workaround to get sane testsuite results.
> 
>   tree offload_table = build_zero_cst (ptr_type_node);
> 
> The failures on AIX are:
> 
> FAIL: libgomp.c/examples-4/e.50.1.c (test for excess errors)
> Excess errors:
> ld: 0711-317 ERROR: Undefined symbol: __OFFLOAD_TABLE__
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.
> 
> WARNING: libgomp.c/examples-4/e.50.1.c compilation failed to produce
> executable

Did you try the proposed patch to fix this?

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01479.html

On darwin this resolves the failures when coupled with a fix for PR64635.

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01509.html

[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components

[paul.richard.thomas at gmail dot com]

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

paul.richard.thomas at gmail dot com  
changed:

   What|Removed |Added

 CC||paul.richard.thomas at gmail 
dot c
   ||om

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Created attachment 34475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34475&action=edit
Fix for the PR

Bootstraps and regtests on x86_64/FC21

2015-01-18  Paul Thomas  

PR fortran/64578
* trans-expr.c (gfc_trans_subcomponent_assign): Use a deep copy
for allocatable components, where the source is a variable.

2015-01-18  Paul Thomas  

PR fortran/64578
* gfortran.dg/block_13.f08: New test

[Bug fortran/64654] New: problem of handling character arguments in parent of an 'entry' with fewer arguments leads at -O0

[d.pashov at gmail dot com]

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

Bug ID: 64654
   Summary: problem of handling character arguments in parent of
an 'entry' with fewer arguments leads at -O0
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.pashov at gmail dot com

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

Incorrect code is generated with -O0 or -fcheck=all for a subroutine having a
character argument of passed length and which also contains entries with
different (or fewer) arguments. Example test case is attached. 

The executable crashes with SIGSERV right after entering the entry, before the
first executable statement in the entry. I suspect it tries to resolve the
charater arguments of the parent subroutine routine which have their 'len'
passed. It does not happen for other arguments or len=* or array arguments.
Some samples are in the example file.

The problem seemigly goes away for -O1 and higher optimisation levels if
-fcheck=all is not used. While the program the works as expected it makes
debugging inconvenient. I did check the f2008 standard carefully and came to
the conclusion that the code is not doing anything in violation.

I have found it on v4.8.1 and have the impresison that it did not exist some
time before but could not find a working version (only tried 4.6). v4.8.3,
v4.9.0 and 5.0 also have the bug.

Results of running the code with varios configurations are in a comment in the
attached file.

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
And the reason for that is that aarch64 again changed ABI, what a stable port
:(.

https://sourceware.org/git/?p=glibc.git;a=commit;h=5c40c3bab2fddaca8cfe12d75944d1fef8adf1a4

[Bug c/64637] Incorrect location for -Wunused-value warnings in for-loop

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Confirmed, but I think we already have a duplicated PR for this somewhere.

[Bug c++/64643] bad location for multiple fields in union initialized

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
You can find the code in gcc/cp/class.c. You'll need to replace:

error ("multiple fields in union %qT initialized", t);

with something like:

error_at (loc2, "multiple fields in union %qT initialized", t);
inform (loc1, "a field is already initialized here");

where the tricky part is to set loc1 and loc2 appropriately.

[Bug c++/64644] "warning: anonymous union with no members" should be an error with -pedantic-errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
A untested patch, feel free to test it and submit it.

Index: decl2.c
===
--- decl2.c (revision 218749)
+++ decl2.c (working copy)
@@ -1604,11 +1604,11 @@ finish_anon_union (tree anon_union_decl)
   main_decl = build_anon_union_vars (type, anon_union_decl);
   if (main_decl == error_mark_node)
 return;
   if (main_decl == NULL_TREE)
 {
-  warning (0, "anonymous union with no members");
+  pedwarn (input_location, 0, "anonymous union with no members");
   return;
 }

   if (!processing_template_decl)
 {

[Bug c/64639] false negative of -Wunused-value

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
b = (0, (a = 0) != 0, 0);

gets somehow transformed into

b = (a = 0B) != 0B;, 0;

(or the pretty-printer in tree-original cannot actually represent the internal
AST).

The warning is bizarre anyway.

[Bug c/64648] Incorrect message description of -Wunused-value

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Hopefully we'll sort it out in GCC 6.

[Bug c/64648] Incorrect message description of -Wunused-value

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-18
 CC||manu at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(a = 0) >= 0; gets transformed into (a = 0); , 1;

This is some undesired early folding.

RE: gcc 4.9.2 cygwin64 internal error parsing decimal float point values

[Marc Reynolds]

If the bug is present then it will occur at any optimization level.  

Given this further information I investigated and discovered the problem.  My 
system somehow had a broken cygmpfr-4.dll installed in /bin.  Given that the 
assert was from MPFR I should have checked this earlier but I naively assumed 
that MPFR would have been statically linked.

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Well, for the old uid/git we can temporarily also just cherry pick upstream
r223925.  Even with that patch I'm running into:
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__1062' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1288:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \
   ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1062:1:
note: in expansion of macro 'CHECK_SIZE_AND_OFFSET'
 CHECK_SIZE_AND_OFFSET(ipc_perm, mode);

[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
Author: pault
Date: Sun Jan 18 12:21:38 2015
New Revision: 219814

URL: https://gcc.gnu.org/viewcvs?rev=219814&root=gcc&view=rev
Log:
2015-01-18  Paul Thomas  

PR fortran/55901
* primary.c (gfc_match_varspec): Exclude dangling associate-
names with dimension 0 from being counted as arrays.
* resolve.c (resolve_assoc_var): Sub-strings are permissible
for associate-names, so exclude characters from the test for
misuse as arrays.
* trans-decl.c (gfc_get_symbol_decl): Associate-names can use
the hidden string length variable of their associated target.
Signal this by setting 'length' to a constant, if the decl for
the string length is a variable.

2015-01-18  Paul Thomas  

PR fortran/55901
* gfortran.dg/associate_1.f03: Allow test for character with
automatic length.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_1.f03

[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 64653 has been marked as a duplicate of this bug. ***

[Bug c++/64653] Incomplete emission of D1/D2 destructors when optimising -- link failure with gold

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
This is an exact dup of PR64163. As Jakub wrote the issue is fixed already.

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

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
oh, and IIRC, the shlib suffix for AIX is .a so there might be another case to
placed.

[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
this seems reasonable.

=

However, for the record:

* if a shared library is User-facing and needs to be passed to ld64, then the
convention is that the suffix = .dylib

* if it's part of a framework, then the suffix is usually omitted.



* If it's a plug-in only dlopen-ed by a specific process, then the suffix can
be whatever you like (e.g. it could be .gomp-plugin to make it clear what its
purpose is).

Probably not worth the configuration-fu to achieve this tho.

[Bug c++/64653] Incomplete emission of D1/D2 destructors when optimising -- link failure with gold

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Try r219696 or newer?