[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #8) (In reply to H.J. Lu from comment #6) /export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -flto -Wl,-Bsymbolic -g -O2 -fsymbolic -shared -o libb.so b.o a.o Will the LTO be required here? Or will it work without LTO too? Dump of assembler code for function bar: 0x05e0 +0: movl $0x1e,0x2002be(%rip)# 0x2008a8 a 0x05ea +10:retq End of assembler dump. LTO is required only when definition and references aren't in the same file. I've been accomplishing the same with protected visibility, but I keep running into linker bugs, so I haven't been able to enable it by default. Looks like the option here will be the proper solution. Protected data symbol means that it can't be pre-emptied. It doesn't mean its address won't be external. This is true for pointer to protected function. With copy relocation, address of protected data defined in the shared library may also be external. We only know that for sure at run-time: https://sourceware.org/bugzilla/show_bug.cgi?id=17711 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248 What you want is -fsymbolic with -Bsymbolic.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This is an exact dup of bug 14319. *** This bug has been marked as a duplicate of bug 14319 ***
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #8 from Paul Thomas pault at gcc dot gnu.org ---
Created attachment 35400
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35400action=edit
Draft Patch
The attached patch bootstraps and regtests with Andre's patch for .. and
pr65841 remains fixed. Have extended Mikael's test case to include a function
call to verify that there are no memory leaks.
! { dg-do run }
!
! PR fortran/65792
! The evaluation of the argument in the call to new_prt_spec2
! failed to properly initialize the comp component.
! While the array contents were properly copied, the array bounds remained
! uninitialized.
!
! Contributed by Dominique D'Humieres domi...@lps.ens.fr
program main
implicit none
integer, parameter :: n = 2
type :: string_t
character(LEN=1), dimension(:), allocatable :: chars
end type string_t
type :: string_container_t
type(string_t) :: comp
end type string_container_t
type(string_t) :: prt_in, tmp, tmpa(n)
type(string_container_t) :: tmpc, tmpca(n)
integer :: i, j, k
do i=1,16
! scalar elemental function with structure constructor
prt_in = string_t([D])
tmpc = new_prt_spec2 (string_container_t(prt_in))
print *, tmpc%comp%chars
deallocate (prt_in%chars)
deallocate(tmpc%comp%chars)
tmpc = new_prt_spec2
(string_container_t(new_str_t([h,e,l,l,o])))
print *, tmpc%comp%chars
deallocate(tmpc%comp%chars)
end do
contains
impure elemental function new_prt_spec2 (name) result (prt_spec)
type(string_container_t), intent(in) :: name
type(string_container_t) :: prt_spec
prt_spec = name
end function new_prt_spec2
function new_str_t (name) result (prt_spec)
character (*), intent(in), dimension (:) :: name
type(string_t) :: prt_spec
prt_spec = string_t(name)
end function new_str_t
end program main
I will submit tomorrow evening.
Paul
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #3) Thanks H.J.! Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add -fsymbolic in GCC 5+, but can't add it prior because the option didn't BTW, you should add -fsymbolic to -fPIC if the shared library will be created by -Bsymbolic. It will improve shared library performance.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to H.J. Lu from comment #5)
BTW, you should add -fsymbolic to -fPIC if the shared library will be
created by -Bsymbolic. It will improve shared library performance.
Here is an example:
[hjl@gnu-tools-1 pr65886-lto]$ cat a.c
int a = -1;
[hjl@gnu-tools-1 pr65886-lto]$ cat b.c
extern int a;
void
bar ()
{
a = 30;
}
[hjl@gnu-tools-1 pr65886-lto]$ vi b.c
[hjl@gnu-tools-1 pr65886-lto]$ cat a.c
int a = -1;
[hjl@gnu-tools-1 pr65886-lto]$ cat b.c
extern int a;
void bar () { a = 30; }
[hjl@gnu-tools-1 pr65886-lto]$ make libb.so
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -g -O2 -fsymbolic -fPIC -flto
-c -o b.o b.c
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -g -O2 -fsymbolic -fPIC -flto
-c -o a.o a.c
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -flto -Wl,-Bsymbolic -g -O2
-fsymbolic -shared -o libb.so b.o a.o
[hjl@gnu-tools-1 pr65886-lto]$ gdb libb.so
GNU gdb (GDB) Fedora 7.8.2-38.fc21
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from libb.so...done.
(gdb) disass bar
Dump of assembler code for function bar:
0x05e0 +0: movl $0x1e,0x2002be(%rip)# 0x2008a8
a
0x05ea +10:retq
End of assembler dump.
(gdb)
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #8 from Thiago Macieira thiago at kde dot org --- (In reply to H.J. Lu from comment #6) (In reply to H.J. Lu from comment #5) BTW, you should add -fsymbolic to -fPIC if the shared library will be created by -Bsymbolic. It will improve shared library performance. Will do. /export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -flto -Wl,-Bsymbolic -g -O2 -fsymbolic -shared -o libb.so b.o a.o Will the LTO be required here? Or will it work without LTO too? Dump of assembler code for function bar: 0x05e0 +0: movl $0x1e,0x2002be(%rip)# 0x2008a8 a 0x05ea +10: retq End of assembler dump. I've been accomplishing the same with protected visibility, but I keep running into linker bugs, so I haven't been able to enable it by default. Looks like the option here will be the proper solution.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #7) You're not accounting for loss of performance in the shared libraries that can't use -Bsymbolic due to the copy relocations, both at load-time (relocations by name) and at runtime (indirect addressing to local symbols). Maybe our experiences with shared libraries isn't the same: mine is that libraries are 10x bigger and more complex than the applications using them. So I submit that your benchmarks are incomplete. The keyword here is psABI compliant. Since your shared library isn't psABI compliant, all bets are off.
[Bug c/65891] New: -Wlogical-op now warns about logical ‘and’ of equal expressions even when different types/sizeofs are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891
Bug ID: 65891
Summary: -Wlogical-op now warns about logical ‘and’ of equal
expressions even when different types/sizeofs are
involved
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gerald at pfeifer dot com
CC: polacek at redhat dot com
Target Milestone: ---
Since 2015-04-21 Marek Polacek pola...@redhat.com
PR c/63357
* c-common.c (warn_logical_operator): Warn if the operands have the
same expressions.
we also diagnose code the following
typedef int r_fun_t (int);
r_fun_t * text_funcs[] = {0,0,0};
int report (unsigned t)
{
typedef int s_fun_t (long, char);
static s_fun_t * GUI_funcs[3];
return (t sizeof text_funcs / sizeof text_funcs[0]
t sizeof GUI_funcs / sizeof GUI_funcs[0]);
}
with
input: In function ‘report’:
input:8:58: warning: logical ‘and’ of equal expressions [-Wlogical-op]
return (t sizeof text_funcs / sizeof text_funcs[0]
^
when these two conditions are about two different types, defined in two
different locations, and the sizes are set differently.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #7 from Thiago Macieira thiago at kde dot org --- (In reply to H.J. Lu from comment #4) (In reply to Thiago Macieira from comment #3) Thanks H.J.! Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add -fsymbolic in GCC 5+, but can't add it prior because the option didn't exist. Please leave that for a release or two so that we can adapt Linux kernel has things like M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) It adds -m16 only if it exits. Why can't KDE do something like this? There are many ways to achieve it and it works with all compilers. We can. The problem is not the ability, it's the need to do it. No buildsystem currently has support for -fsymbolic, since it doesn't exist yet. However, the lack of such option will produce subtle bugs. I'm asking for a grace period until the changes propagate. I can add a runtime check to QtCore, though. By default, GCC should be psABI compliant. -Bsymbolic isn't psABI compliant since the resulting shared library doesn't work with normal executable. I don't believe -fsymbolic should be the default, just like that -Bsymbolic shouldn't be the default for linker either. I would argue that those should be the default and that we're optimising for the wrong thing. For example, in your email with the patch, you said: Some experiments on google and SPEC CPU benchmarks show that the extra instruction affects performance by 1% to 5%. You're not accounting for loss of performance in the shared libraries that can't use -Bsymbolic due to the copy relocations, both at load-time (relocations by name) and at runtime (indirect addressing to local symbols). Maybe our experiences with shared libraries isn't the same: mine is that libraries are 10x bigger and more complex than the applications using them. So I submit that your benchmarks are incomplete.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Frédéric Buclin LpSolit at netscape dot net --- Upgrade done. :)
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Also if we follow that defect resolution, basically strict aliasing does not mean anything any more and we would have to turn off strict aliasing for all structs.
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 65892 has been marked as a duplicate of this bug. ***
[Bug c++/65890] New: [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
Bug ID: 65890
Summary: [C++03]sizeof(qualified-id) accepted when the operand
denotes a non-static member
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
struct Tag { int m; };
int main()
{
sizeof((Tag::m));
}
According to ISO C++03 5.1/10, this is not well-formed. (But C++11 should
work.) However, G++ 4.9.1 wrongly accepted it even with -std=c++03
-pedantic-errors.
(I have no GCC 5 distro so have not tested it.)
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 --- Comment #2 from frankhb1989 at gmail dot com --- Tested here: http://melpon.org/wandbox/, both G++ 5.1 and 6.0 accepted the invalid code.
[Bug c/65892] New: gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Bug ID: 65892
Summary: gcc fails to implement N685 aliasing of union members
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As the following program derived from the snippet in WG14 paper N685
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n685.htm) shows, GCC fails to
take into account the C99 and C11 permission for struct members of unions that
declare initial members of compatible types to alias one another.
$ cat n685.c /build/gcc-65479/gcc/xgcc -B/build/gcc-65479/gcc -O2
-fstrict-aliasing n685.c ./a.out
#include assert.h
union U {
struct t1 { int m; } s1;
struct t2 { int m; } s2;
};
int f (struct t1 *p1, struct t2 *p2)
{
// union U visible here, p1-m and p2-m may alias
if (p1-m 0)
p2-m = -p2-m;
return p1-m;
}
int main (void)
{
union U u = { .s1 = { -1 } };
int n = f (u.s1, u.s2);
assert (1 == n);
return 0;
}
a.out: n685.c:21: main: Assertion `1 == n' failed.
Aborted (core dumped)
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Some folks think that resolution is not fully correct.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #7) (In reply to H.J. Lu from comment #4) (In reply to Thiago Macieira from comment #3) Thanks H.J.! Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add -fsymbolic in GCC 5+, but can't add it prior because the option didn't exist. Please leave that for a release or two so that we can adapt Linux kernel has things like M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) It adds -m16 only if it exits. Why can't KDE do something like this? There are many ways to achieve it and it works with all compilers. We can. The problem is not the ability, it's the need to do it. Now, you have a need :-). No buildsystem currently has support for -fsymbolic, since it doesn't exist yet. However, the lack of such option will produce subtle bugs. I'm asking for a grace period until the changes propagate. I don't think GCC default should cater shared libraries which aren't psABI compliant. It is the risk you take when using a non-psABI compliant library.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #3 from Thiago Macieira thiago at kde dot org --- Thanks H.J.! Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add -fsymbolic in GCC 5+, but can't add it prior because the option didn't exist. Please leave that for a release or two so that we can adapt buildsystems.
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Thiago Macieira from comment #3) Thanks H.J.! Can I ask that -fsymbolic be the default? Otherwise, code with -fPIE MUST add -fsymbolic in GCC 5+, but can't add it prior because the option didn't exist. Please leave that for a release or two so that we can adapt Linux kernel has things like M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS)) It adds -m16 only if it exits. Why can't KDE do something like this? There are many ways to achieve it and it works with all compilers. buildsystems. By default, GCC should be psABI compliant. -Bsymbolic isn't psABI compliant since the resulting shared library doesn't work with normal executable. I don't believe -fsymbolic should be the default, just like that -Bsymbolic shouldn't be the default for linker either.
[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890 --- Comment #1 from frankhb1989 at gmail dot com --- Oops, wrong version of case pasted ... I once wanted to use this minimal one: sizeof(Tag::m); Nevertheless, the conclusion is the same for this issue. (There are other mess, e.g. Clang++ 3.6 wrongly interpret 'decltype((Tag::m))' as pointer to member but I think G++ is right here).
[Bug c/65881] no documentation of __uint128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65881 Shawn Landden shawn at churchofgit dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Shawn Landden shawn at churchofgit dot com --- unsigned __int128
[Bug c/65891] -Wlogical-op now warns about logical ‘and’ of equal expressions even when different types/sizeofs are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-25 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Sorry. I'll look into that.
[Bug target/64782] -mcpu=native should be supported on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64782 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed: http://cagit1.caveonetworks.com/git/?p=toolchain/gcc.git;a=commit;h=8b81ce60cb7975ad457d58d237d1b533f81ecd7c --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8b81ce60cb7975ad457d58d237d1b533f81ecd7c Aka revision 222415 .
[Bug target/64782] -mcpu=native should be supported on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64782 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed: http://cagit1.caveonetworks.com/git/?p=toolchain/gcc.git;a=commit;h=8b81ce60cb7975ad457d58d237d1b533f81ecd7c --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8b81ce60cb7975ad457d58d237d1b533f81ecd7c Aka revision 222415 .
[Bug c/52085] incomplete enum not completed correctly if packed was used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed for GCC 6.
[Bug libstdc++/65883] New: numeric_limitsunsigned __int128::max() returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65883 Bug ID: 65883 Summary: numeric_limitsunsigned __int128::max() returns incorrect value Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: john at johnmaddock dot co.uk std::numeric_limitsunsigned __int128::max() returns 0x7fff which is definitely not 2^128-1. Looks like a cut and paste error from numeric_limits__int128? This is on Xubuntu 64-bit. This is a showstopper for Boost.Multiprecision which has asserts that are incorrectly triggered by the bug. Regards, John Maddock.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net --- (In reply to Jerry DeLisle from comment #10) gfortran currently does this with default formatting, list directed outout: - ( 1., 0.) ( -1.0002E-25, 0.) ( -1.0002E-25, 0.) ( 1., 0.) ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23) ( 1., 0.) ( -1.0002E-25, 0.) - I have my experimental doing this: case A - (1.,0.) (-0.1000E-24,0.) (-0.1000E-24,0.)(1.,0.) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0.) (-0.1000E-24,0.) - I could also do this: case B - (1.,0. ) (-0.1000E-24,0. ) (-0.1000E-24,0. ) (1.,0. ) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0. ) (-0.1000E-24,0. ) - or is there some other arrangement? I think your case B is invalid, because no spaces are allowed in constants, i.e. between the parentheses (see above). There is also case C (right-flush in 2*w+3): - (1.,0.) (-0.1000E-24,0.) (-0.1000E-24,0.) (1.,0.) (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22) (1.,0.) (-0.1000E-24,0.) - The standard says: Numeric editing, General rules: ... On output, the representation is right justified in the field. If the number of characters produced by the editing is smaller than the field width, leading blanks are inserted in the field.
[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
Summary|Internal compiler error:|[5/6 Regression] Internal
|Error reporting routines|compiler error: Error
|re-entered |reporting routines
||re-entered
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat json.ii
template bool struct A
{
typedef int type;
};
template typename _Tp struct numeric_limits
{
static constexpr _Tp
max ()
{
return 0;
}
};
template struct numeric_limitslong
{
static constexpr int
max ()
{
return 5;
}
};
template typename RHS, RHS rhs, typename LHS
void greater_than_impl (typename A(rhs numeric_limitsLHS::max ())::type)
{
}
template typename, int rhs, typename LHS void greater_than (LHS)
{
greater_than_implint, rhs, LHS;
}
struct B
{
long m_fn1 () const;
template class T T m_fn2 () const;
};
template class, class Src
void
to (Src value)
{
greater_thanlong, numeric_limitslong::max () (value);
}
bool asImpl___trans_tmp_1;
template class T
T
B::m_fn2 () const
{
toT (asImpl___trans_tmp_1);
};
long
B::m_fn1 () const
{
m_fn2long ();
}
markus@x4 tmp % g++ -Wbool-compare -c -std=c++11 json.ii
json.ii: In instantiation of ‘void greater_than(LHS) [with
template-parameter-1-1 = long int; int rhs = 5; LHS = bool]’:
json.ii:38:52: required from ‘void to(Src) [with template-parameter-1-1 =
long int; Src = bool]’
json.ii:45:9: required from ‘T B::m_fn2() const [with T = long int]’
json.ii:50:16: required from here
json.ii:22:41: warning: comparison of constant ‘5’ with boolean expression is
always true [-Wbool-compare]
void greater_than_impl (typename A(rhs numeric_limitsLHS::max ())::type)
^
json.ii:22:41: warning: comparison of constant ‘5’ with boolean expression is
always true [-Wbool-compare]
‘
Internal compiler error: Error reporting routines re-entered.
0x611701 build_new_op_1
../../gcc/gcc/cp/call.c:5691
0x61238e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:5750
0x73f5ce build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3805
0x676cda tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14730
0x6663af tsubst_expr
../../gcc/gcc/cp/pt.c:14352
0x670f4c tsubst_template_arg
../../gcc/gcc/cp/pt.c:9654
0x66c26a tsubst_template_args
../../gcc/gcc/cp/pt.c:10205
0x682cb0 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10402
0x66e65d tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12366
0x6f2b40 dump_template_bindings
../../gcc/gcc/cp/error.c:369
0x6f2b40 dump_substitution
../../gcc/gcc/cp/error.c:1448
0x6f6214 decl_to_string
../../gcc/gcc/cp/error.c:2910
0x6f6214 cp_printer
../../gcc/gcc/cp/error.c:3494
0x1350407 pp_format(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.c:613
0x1350c90 pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.c:672
0x1350d6d pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/gcc/pretty-print.c:875
0x6e84fa print_instantiation_full_context
../../gcc/gcc/cp/error.c:3273
0x6e84fa maybe_print_instantiation_context
../../gcc/gcc/cp/error.c:3417
0x6f4db3 cp_diagnostic_starter
../../gcc/gcc/cp/error.c:3109
0x134d499 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:866
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- Still in 5.1.0 at trans-array.c:2223
[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- Stiil in 5.1.0 at interface.c:2701
[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Ever confirmed|0 |1 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Well, that this include is required seems to me like a bug in mingw.org, as wincrypt.h should be auto-included by windows.h. Nevertheless this is a trivial patch, so it is ok. Please post it to ML, and I will take care to apply. Thanks
[Bug c++/65882] New: Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 Bug ID: 65882 Summary: Internal compiler error: Error reporting routines re-entered Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yan12125 at gmail dot com I invoke the following command: g++ -nostdlib -Wbool-compare -Wno-unused -Wno-deprecated-declarations -s -std=c++11 json.ii json.ii is the attached file. It's from hhvm. https://github.com/facebook/folly/blob/master/folly/json.cpp I encounter no problem if compiling folly separately. If I compile the whole hhvm, the following error occurs. The result is: https://gist.github.com/yan12125/b5498cb6ac2be4a5649a The compiler version is: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5.1.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=c++98 Thread model: posix gcc version 5.1.0 (GCC) OS: Arch Linux x86_64 I use the official gcc-multilib package $ pacman -Qi gcc-multilib Name : gcc-multilib Version: 5.1.0-1 Description: The GNU Compiler Collection - C and C++ frontends for multilib Architecture : x86_64 URL: http://gcc.gnu.org Licenses : GPL LGPL FDL custom Groups : multilib-devel Provides : gcc=5.1.0-1 Depends On : gcc-libs-multilib=5.1.0-1 binutils=2.25 libmpc Optional Deps : None Required By: clang dkms dmd Optional For : None Conflicts With : gcc Replaces : None Installed Size : 108.38 MiB Packager : Jan Alexander Steffens (heftig) jan.steff...@gmail.com Build Date : Thu 23 Apr 2015 09:33:01 PM CST Install Date : Sat 25 Apr 2015 01:48:42 PM CST Install Reason : Explicitly installed Install Script : Yes Validated By : Signature
[Bug c++/65882] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 --- Comment #2 from yan12125 at gmail dot com --- Sorry, I don't know why the attachment is lost. I re-attach the file here: https://gist.githubusercontent.com/yan12125/b5498cb6ac2be4a5649a/raw/json.ii
[Bug fortran/64230] [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Do you see this too? Yes, and the test runs if I remove/comment the line Deallocate (x) The test gfortran.dg/class_allocate_18.f90 has the same problem: see pr64921. I hope that reopening this PR is acceptable. If not then just let me know and I will happily file a new one. IMO it is better to file a new PR rather than reopening an old one. In the present case, I think the problem reported in comment 9 is already tracked by pr64921 (duplicate).
[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 --- Comment #4 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) This PR is fixed by Andre's patch for pr59678 (all tests). Note that the last test in comment 1 segfault with only the [fist patch] for pr65792 + the one for pr59678. So this is another conflict between the two patches. I haven't had time to keep track of the gfortran list. However, whilst travelling I have worked on this bug and came to the same analysis as Andre and nearly the same patch :-) I am therefore reviewing Andre's patch for PR59678. I just applied it to trunk and am regtesting. Watch this space in the next few hours! Cheers Paul
[Bug c++/65882] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-04-25 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- There is no attachment. (you can compress the file if it is too large)
[Bug c/52085] incomplete enum not completed correctly if packed was used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sat Apr 25 10:12:01 2015 New Revision: 222440 URL: https://gcc.gnu.org/viewcvs?rev=222440root=gccview=rev Log: PR c/52085 * c-decl.c (finish_enum): Copy over TYPE_ALIGN. Also check for mode attribute. * gcc.dg/enum-incomplete-2.c: New test. * gcc.dg/enum-mode-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/enum-incomplete-2.c trunk/gcc/testsuite/gcc.dg/enum-mode-1.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65883] [5/6 Regression] numeric_limitsunsigned __int128::max() returns incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65883 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Summary|numeric_limitsunsigned |[5/6 Regression] |__int128::max() returns|numeric_limitsunsigned |incorrect value |__int128::max() returns ||incorrect value Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Indeed, the specialization for struct numeric_limitsunsigned TYPE uses TYPE instead of unsigned TYPE for max :-(
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #7 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Jonathan Wakely from comment #6) And even if they don't read the libstdc++ documentation, std::search doesn't work with input iterators, that's always been true: https://www.sgi.com/tech/stl/search.html http://en.cppreference.com/w/cpp/algorithm/search The code is simply broken and should be fixed. Is there e reason for gcc not to detect such wrong code issues by default? Perhaps gcc 6 should finally default to --enable-concept-checks.
[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Thomas Henlich from comment #12) --- snip --- There is also case C (right-flush in 2*w+3): --- snip --- Oh yes, Thanks Thomas. I now see you mentioned this in your previous comment. It will require a different approach than what I have now. I will see what I can come up with.
[Bug c++/65885] New: lambda expressions in templates fail to capture `const int' variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65885
Bug ID: 65885
Summary: lambda expressions in templates fail to capture `const
int' variables
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: myoga.murase at gmail dot com
The following c++11 code does not compile with gcc-5.1.0 while it is fine with
gcc-4.9.2, and gcc-4.8.3.
[user@host gcc]$ cat lambda.cpp
int gvar=1;
templateint I
void tfun(){
int const var=gvar;
auto f=[=](){return var*var;};
}
void fun(){
tfun1();
}
[user@host gcc]$ /home/user/opt/gcc/5.1.0/bin/g++-5.1 -v
Using built-in specs.
COLLECT_GCC=/home/user/opt/gcc/5.1.0/bin/g++-5.1
COLLECT_LTO_WRAPPER=/home/user/opt/gcc/5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --program-suffix=-5.1
--prefix=/home/user/opt/gcc/5.1.0 --with-gmp=/home/user/local
--with-mpfr=/home/user/local --with-mpc=/home/user/local --disable-libjava
Thread model: posix
gcc version 5.1.0 (GCC)
[user@host gcc]$ /home/user/opt/gcc/5.1.0/bin/g++-5.1 -std=c++11 -c lambda.cpp
lambda.cpp: In instantiation of 'tfun()::lambda() [with int I = 1]':
lambda.cpp:6:12: required from 'struct tfun() [with int I = 1]::lambda()'
lambda.cpp:6:31: required from 'void tfun() [with int I = 1]'
lambda.cpp:10:11: required from here
lambda.cpp:6:26: error: redeclaration of 'const int var'
auto f=[=](){return var*var;};
^
lambda.cpp:6:26: note: 'const int var' previously declared here
lambda.cpp: In instantiation of 'void tfun() [with int I = 1]':
lambda.cpp:10:11: required from here
lambda.cpp:6:10: sorry, unimplemented: non-trivial designated initializers not
supported
auto f=[=](){return var*var;};
^
I also tried with the options, `-Wall -Wextra' and `-fno-strict-aliasing
-fwrapv -fno-aggressive-loop-optimizations', but nothing changed. The error is
also reproduced with the latest version of GCC:
http://melpon.org/wandbox/permlink/yOs7mqpdpKKGNllN
The error seems to occur in the following situation:
- A lambda expression is in a function template or a class template.
- A variable of `const int' is implicitly captured with `[=]' or `[]'.
(Interestingly, the error is not reproduced with `const double' or `int'
variables.)
- The variable is used more than once in the lambda expression.
- The variable is initialized with a non-constant value (which cannot be
statically determined).
This may be related to
Bug 64791 (RESOLVED FIXED) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jack Howarth from comment #7) Is there e reason for gcc not to detect such wrong code issues by default? Read the docs, the concept checks only enforce C++03 requirements, so turning them on by default would erroneously reject valid C++11 programs that rely on the relaxed Perhaps gcc 6 should finally default to --enable-concept-checks. Definitely not. The reason I haven't just closed this as INVALID is that in C++11 mode we could add unconditional static assertions, but someone needs to do the work of adding those assertions, and making sure they test the right concepts (which may differ from the existing C++03 checks).
[Bug tree-optimization/65887] New: remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887
Bug ID: 65887
Summary: remove va_arg ap copies
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
[ Discussed here: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01262.html ]
When compiling gcc.target/x86_64/abi/callabi/vaarg-6.c, at original we have:
...
;; Function do_cpy2 (null)
{
char * e;
char * e;
e = VA_ARG_EXPR argp;
e = VA_ARG_EXPR argp;
if (e != b)
{
abort ();
}
}
...
and after gimplify we have:
...
do_cpy2 (char * argp)
{
char * argp.1;
char * argp.2;
char * b.3;
char * e;
argp.1 = argp;
e = VA_ARG (argp.1, 0B);
argp = argp.1;
argp.2 = argp;
e = VA_ARG (argp.2, 0B);
argp = argp.2;
b.3 = b;
if (e != b.3) goto D.1373; else goto D.1374;
D.1373:
abort ();
D.1374:
}
...
We'd like to generate:
...
e = VA_ARG (argp, 0B);
...
instead of:
...
argp.1 = argp;
e = VA_ARG (argp.1, 0B);
argp = argp.1;
...
The code generating the copyback 'argp = argp.1' is in gimplify_modify_expr.
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from vries at gcc dot gnu.org --- patch committed. Filed review comment from https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01262.html : ... But I wonder if we can't fix things to not require that odd extra copy. In fact that we introduce ap.1 looks completely bogus to me SNIP So ... what breaks if we simply remove this odd fixup? ... as PR65887 - remove va_arg ap copies. Marking resolved, fixed.
[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #13 from David Stone david at doublewise dot net --- I understand the difference between the two. I just prefer an opt-out system of warnings instead of opt-in. If absolutely no one could possibly want a warning, it shouldn't exist. If some users would want the warning, I may be one of those users at some point and I'd like to see it.
[Bug other/65884] New: libgccjit fails to link on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65884 Bug ID: 65884 Summary: libgccjit fails to link on ia64-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen on the gcc-5-branch, ignoring PR65874, and trying to build libgccjit with the just build gcc. binutils used is 2.22. /build/buildd/gcc-5-5.1.0/build/gcc/xg++ -B/build/buildd/gcc-5-5.1.0/build/gcc/ -B/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/src/.libs -B/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -I/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/include -I/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/include/ia64-linux-gnu -I/build/buildd/gcc-5-5.1.0/src/libstdc++-v3/libsupc++ -L/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/src/.libs -L/build/buildd/gcc-5-5.1.0/build/ia64-linux-gnu/libstdc++-v3/libsupc++/.libs -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -lm -o libgccjit.so.0.0.1 -shared \ attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a libcommon.a \ ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -lz \ \ -Wl,--version-script=../../src/gcc/jit/libgccjit.map \ -Wl,-soname,libgccjit.so.0 /usr/bin/ld: libgccjit.so.0.0.1: short data segment overflowed (0x422788 = 0x40) collect2: error: ld returned 1 exit status make[4]: *** [libgccjit.so.0.0.1] Error 1 make[4]: Leaving directory `/build/buildd/gcc-5-5.1.0/build-jit/gcc' make[3]: *** [all-gcc] Error 2 complete build log at https://launchpadlibrarian.net/204459587/buildlog_ubuntu-lucid-ia64.gcc-5_5.1.0-0ubuntu11~10.04.1_BUILDING.txt.gz
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #12 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01543.html
[Bug target/65886] [5/6 Regression] External reference in PIE to DSO created with -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-25 Version|5.0 |5.1.0 Ever confirmed|0 |1
[Bug target/65886] New: [5/6 Regression] External reference in PIE to DSO created with -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
Bug ID: 65886
Summary: [5/6 Regression] External reference in PIE to DSO
created with -Wl,-Bsymbolic
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Copy relocation in PIE is incompatible with DSO created with -Wl,-Bsymbolic:
[hjl@gnu-tools-1 copyreloc-2]$ cat x.c
extern int a;
extern int *a_p (void);
extern void bar (void);
extern void *bar_p (void);
int main()
{
if (bar_p () != bar)
__builtin_abort();
if (a_p () != a)
__builtin_abort();
bar ();
if (a != 30)
__builtin_abort();
return 0;
}
[hjl@gnu-tools-1 copyreloc-2]$ cat bar.c
int a;
void
bar ()
{
a = 30;
}
void *
bar_p ()
{
return bar;
}
int *
a_p ()
{
return a;
}
[hjl@gnu-tools-1 copyreloc-2]$ make
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -g -O2 -fPIE -c -o x.o x.c
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -g -O2 -fPIC -c -o bar.o
bar.c
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -Wl,-Bsymbolic -shared -o
libbar.so bar.o
/export/build/gnu/gcc-5/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-5/build-x86_64-linux/gcc/ -pie -o x x.o libbar.so
-Wl,-rpath,.
./x
Makefile:13: recipe for target 'all' failed
make: *** [all] Aborted (core dumped)
[hjl@gnu-tools-1 copyreloc-2]$
[Bug c++/65843] [5/6 Regression] multiple use of const variable in lamba in template function causes compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||myoga.murase at gmail dot com --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 65885 has been marked as a duplicate of this bug. ***
[Bug c++/65885] lambda expressions in templates fail to capture `const int' variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65885 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- duplicate *** This bug has been marked as a duplicate of bug 65843 ***
[Bug target/65886] [5/6 Regression] External reference in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01546.html
[Bug c/65888] New: Need a way to disable copy relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65888 Bug ID: 65888 Summary: Need a way to disable copy relocations Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Qt would like to optimise libraries by resolving relocations that loop back into the library in question at link-time, disallowing interposing. The libraries remain position-independent by always resolving symbols via PC-relative addressing or via R_xxx_RELATIVE relocations for what pointers need to be stored in memory (such as virtual tables). Do do that, we use -Bsymbolic or -Bsymbolic-functions. Either way, this is not enough: The problem happens when the symbols used from the libraries get used in the main application. Due to copy relocation and position-dependent code generation, those symbols transfer to the main application: * variables are copy-relocated * functions' entry points are now the PLT location in the application Since the official address of certain variables or functions change, the link-time resolving that happened inside the library is now different from what the application and other libraries will resolve. So far, using -fPIE has been enough to make the main executable not create copy relocations on i386 and x86-64, with GCC 4.9 and earlier, Clang and ICC. GCC 5 breaks that. Given the relative code size of the application vs the libraries (the libraries are at least 10x larger and more complex), I argue that we're optimising for the wrong thing by using copy relocations. It's a historic mistake that needs fixing in the ABI. Please provide a way for libraries to be allowed to use -Bsymbolic and -fvisibility=protected by making applications never use copy relocations. Applications should resolve symbols coming from libraries via indirect, position-independent addressing. We are ok with tagging every symbol in question with a new __attribute__ (they are already all tagged with __attribute__((visibility(default.
[Bug fortran/65889] New: ICE on invalid(?) with sizeof polymorphic variable [OOP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65889 Bug ID: 65889 Summary: ICE on invalid(?) with sizeof polymorphic variable [OOP] Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following testcase causes an ICE with gfortran 6.0 (r222432): module m type n end type n contains subroutine g(ns) class(n), intent(out), allocatable, dimension(:) :: ns write (0,*) sizeof(ns) end subroutine g end module m $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/nfs/17/cond0061/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/nfs/17/cond0061/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 6.0.0 20150424 (experimental) (GCC) $ gfortran -c small.f90 -o small.o small.f90:7:0: write (0,*) sizeof(ns) 1 internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘indirect_ref’ in gfc_conv_intrinsic_sizeof, at fortran/trans-intrinsic.c:5928 0xdd8994 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-trunk/gcc/tree.c:9471 0x706628 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-trunk/gcc/tree.h:2960 0x706628 gfc_conv_intrinsic_sizeof ../../gcc-trunk/gcc/fortran/trans-intrinsic.c:5928 0x70e24f gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-intrinsic.c:8185 0x6ece32 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:7361 0x6f3685 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:7496 0x7150c1 gfc_trans_transfer(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-io.c:2394 0x6b18d7 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1885 0x7121b0 build_dt ../../gcc-trunk/gcc/fortran/trans-io.c:1921 0x6b18f7 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1857 0x6de1df gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5896 0x6b6149 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:2053 0x66e3ad translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:5328 0x66e3ad gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:5538 0x6ae745 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:228 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. It's not clear to me if this is invalid code - see the discussion for PR57305 on how SIZEOF() should work on variables without a declared type. I checked that the testcase for PR57305 still compiles successfully. Wrapping the call to SIZEOF() inside a SELECT TYPE block removes the ICE. Replacing SIZEOF() with STORAGE_SIZE() (as suggested in PR57305) results in a slightly different backtrace: $ gfortran -c small.f90 -o small.o small.f90:7:0: write (0,*) storage_size(ns) 1 internal compiler error: Segmentation fault 0xb7572f crash_signal ../../gcc-trunk/gcc/toplev.c:383 0x70689e gfc_conv_intrinsic_storage_size ../../gcc-trunk/gcc/fortran/trans-intrinsic.c:6067 0x70e8b9 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-intrinsic.c:8189 0x6ece32 gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:7361 0x6f3685 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:7496 0x7150c1 gfc_trans_transfer(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-io.c:2394 0x6b18d7 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1885 0x7121b0 build_dt ../../gcc-trunk/gcc/fortran/trans-io.c:1921 0x6b18f7 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1857 0x6de1df gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5896 0x6b6149 gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:2053 0x66e3ad translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:5328 0x66e3ad gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:5538 0x6ae745 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:228 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/65886] [5/6 Regression] External reference in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||thiago at kde dot org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- *** Bug 65888 has been marked as a duplicate of this bug. ***
[Bug c/65888] Need a way to disable copy relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65888 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Dup. *** This bug has been marked as a duplicate of bug 65886 ***
