[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Iain Sandoe --- fixed on open branches.
[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
--- Comment #14 from Iain Sandoe ---
(In reply to Jeremy Huddleston Sequoia from comment #13)
I fully understand that a (perhaps the most) common use-case is
build=host=target.
However, we want the other use-cases to work (for example, I regularly
cross-host x86-64-darwinxx => powerpc-darwin9, and also use native
{build!=host=target} crosses (essential when porting Ada across versions).
> 1. clang honors $SDKROOT from the environment if it is not passed via
> -isysroot on the command line. That's all gcc needs to do, and then users
> running 'xcrun gcc' would ge this behavior automatically.
This ({$SDKROOT} support) is now implemented, but IMO it's dangerous - since
that will apply everywhere when no --sysroot/-isysroot is given which
could/would break any other case than build=host=target. It's likely to
produce bug reports about cross-builds not working.
> 2. xcrun is not OSS, but the primary functionality that you asked for was
> provided in libxcselect in macOS 10.15, so you wouldn't need to exec xcrun
> to find the path to the SDK.
That's a great addition, we will have to figure out how to incorporate it for
the folks that can use 10.15+.
> 3. I cannot decipher your comment "when clang is using a "different" SDK to
> target a version of MacOS, it is using the runtimes provided by the target
> MacOS version." ... that doesn't quite make sense, so please be a bit more
> specific about which runtime you are referring to (the compiler runtime, the
> OS runtime)... either way I try to interpret it, it makes no sense, so I'm
> not sure how to address this comment, sorry.
when target != host (and target-version < host-version -1) it's safer to use an
SDK that's for the actual target (from an earlier Xcode or Command line tools
SDK). This becomes more and more important when the gap between host and
target version gets larger.
It is obviously essential when doing crosses from x86_64 => powerpc darwin,
since there's no support for powerpc in the current SDKs. It's now also
essential for targeting i686.
So this is just repeating that the OSS use of macOS/Darwin does not necessarily
follow the "only version N and N-1 matter" pattern. Nor are people in a
position to use the latest-and-greatest in all cases; one of my fastest
machines is a 2008 8core xeon mac pro - which cannot go beyond 10.11. In fact,
many places are unwilling to use bleeding edge for production machines too.
> 4. macOS deprecates APIs but will almost never remove them (unless we change
> architectures ... such as when we removed a bunch of deprecated API when
> moving from ppc to intel). Internal / private SPI is subject to removal,
> but we aim to never remove API as that breaks binary compatibility.
That's good to know (for the record, I would not sanction the use of an
internal API for the GCC port, however tempting it might be).
=== attempt at a summary.
In principle, there are 3 SDKs that could matter (where build, host and target
system versions can all be different - analogous to a so-called "Canadian
cross").
1) for the build system version (since we build code that must run on the host
- the generators, and some of the Ada stuff)
That can be provided by doing CC/CXX="xxx --sysroot=" on the configure line.
2) for the host code.
This is usually expected to be provided by the compiler that is targeting the
host.
macOS is an usual case for GCC in that, in principle, we can target all
versions with one compiler, where other systems can expect the
compiler-for-host to reference an appropriate sysroot-for-host.
we are missing a good way to provide the SDK to the compiler in this case (in
fact, I usually just build a cross-compiler with the host macOS as the target
and install it in the usual "linux-y" way).
(as an aside) In the 10.5/6 era it all "just worked" because the SDKs included
support for all the cross-cases, and there were not really any big gaps in the
support.
Now we have a large range of macOS/Darwin versions and the current SDKs won't
support building for perfectly sane hardware (e.g. my 8 core Xeon) much less
the vintage (powerpc).
3) for the target code.
The usual case is to provide --with-sysroot=
As noted before, although the provided SDK path becomes the default, it does
not prevent it from being overridden by a user's command line --sysroot= [and
now also $SDKROOT will override when there's no --sysroot/-isysroot on the
command line]
--with-build-sysroot=dir is allowing for the case that the build system wants
to provide the build time sys root from a different place than the one given by
--with-sysroot=
(so, for example, --with-sysroot=/ ... --with-build-sysroot=/path/to/target/SDK
)
https://gcc.gnu.org/install/configure.html describes in more detail.
This option is not working completely (on other platforms too) so the patch
listed above is a sketch at trying to improve that (albeit incomplete, it
apparently solves some of the issues).
[Bug target/63891] [7 regression] Failure of darwin-weakimport-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63891 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Iain Sandoe --- fixed on open branches
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 --- Comment #5 from Marc Glisse --- Would it make sense to add a fixit hint that removes "constexpr"? I think that might make the warning a bit clearer for some users. On the other hand, if is_constant_evaluated gets removed by P1938, there is no point putting more work into it.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #39 from Jiu Fu Guo --- For small loop (1-2 stmts), in forms of GIMPLE and RTL, it would be around 5-10 instructions: 2-4 insns per stmt, ~4 insns for idx. With current unroller, here is a statistic on spec2017. Using --param max-unrolled-insns=12, there are ~3000 small loops could be unrolled totally, and ~40 of these small loops are located in hot-functions. Using --param max-unrolled-insns=16, there are ~11000 small loops could be unrolled totally, and ~230 of these small loops are located in hot-functions. Using --param max-unrolled-insns=20, there are ~15000 small loops could be unrolled totally, and ~570 of these small loops are located in hot-functions. Using --param max-unrolled-insns=24, there are ~18000 small loops could be unrolled totally, and ~680 of these small loops are located in hot-functions. if max-unrolled-insns<16, just few small loops are unrolled for hot-functions; it may be not very valuable.
[Bug target/92075] New: extracting element from NEON float-vector moves to/from integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92075
Bug ID: 92075
Summary: extracting element from NEON float-vector moves
to/from integer register
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
On ARM, when extracting an element from a float32x2_t expression, i.e.:
float32x2_t v = (...);
float v0 = v[0];
In most cases, gcc moves the element to an general-purpose register and back to
a VFP/Neon register, even at -Ofast. It doesn't seem to happen when v is an
argument or the return value of a non-inline function, but it does happen e.g.
when v is an arithmetic expression or produced by a NEON intrinsic or inline
asm. It doesn't seem to matter how v0 is consumed (i.e. by returning it,
passing it as argument to a function, or consuming it by inline asm).
Some test-cases:
#include
float test1( float32x2_t v ) {
return (v + v)[0];
}
void test2() {
float32x2_t v;
asm( "" : "=w"(v) );
float v0 = v[0];
asm( "" :: "w"(v0) );
}
void foo( float );
void test3( uint32x2_t v ) {
foo( vcvt_n_f32_u32( v, 32 )[0] );
}
output produced by "arm-linux-gnueabihf-gcc-9 (Debian 9.2.1-8) 9.2.1 20190909"
with -Ofast -mcpu=cortex-a8 -mfpu=neon, reformatted for readability:
test1:
vadd.f32 d0, d0, d0
vmov.32 r3, d0[0]
vmov s0, r3
bxlr
test2:
vmov.32 r3, d16[0]
vmov s15, r3
bx lr
test3:
vcvt.f32.u32 d0, d0, #32
vmov.32 r3, d0[0]
vmov s0, r3
b foo(PLT)
This is especially bad on the cortex-A8, where moving from a VFP/Neon register
to an general purpose register causes a severe pipeline stall.
Note btw how in test1 and test3 no move is needed at all: the final move
destination is the register it originally came from, and a different choice of
register allocation can make this also true in test2.
[Bug c++/92076] New: strange strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92076
Bug ID: 92076
Summary: strange strcpy
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: georg.chambert at telia dot com
Target Milestone: ---
Created attachment 47026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47026&action=edit
screenshot of strange strcpy buffer shift, note first two printf
---snippet of code -v
printf("%s\n",prev_buff);
strcpy(str,prev_buff); str[2]=0;// take first part an put
endmark
lastHour = atoi(str);
printf("%s\n",prev_buff);
str[0]=prev_buff[3]; str[1]=prev_buff[4];str[2]=0;// hittar
inget bra i clib
lastMin = atoi(str);
printf(">>>%d<<<%s>>>%d<<<\n",lastHour,str,lastMin);
printf("%s\n",prev_buff);
the bugg (well strangeity then) occur (as per screenshot) between the first and
the second printf,
the prev_buff gets "shifted left", 10positions, BY the strcpy( ) CALL(!!??) ;
in my naive world the prev_buff should be unaltered.
exactly the same sequence of code works without problem in an earlier location,
albeit with other
variables (and without the issue-confining/indicating printouts)
(which is worrying);
-just preceeding
strcpy(str,inbuffer); str[2]=0;// take first part an put
endmark
firstHour = atoi(str);
str[0]=inbuffer[3]; str[1]=inbuffer[4];str[2]=0;// hittar
inget bra i clib
firstMin = atoi(str);
printf(">>>%d<<<>>>%d<<<\n",firstHour,firstMin);
-declaration earlier in program---v
#define WIN32_LEAN_AND_MEAN
#include
#include
#include
using namespace std;
char inbuffer[80];
char prev_buff[80];
char str[10];
has been compiled with following, making no diff ---v
C:\Users\Micron 2.0.DESKTOP-OKJ8P06\Desktop\logg_read>gcc -fno-strict-aliasing
-fwrapv -fno-aggressive-loop-optimizations measProc.cpp
--
AS for the GCC version used:
C:\Users\Micron 2.0.DESKTOP-OKJ8P06>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu
--host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw
--with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586
--with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada
--with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared
--enable-threads --with-dwarf2 --disable-sjlj-exceptions
--enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw
--with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp
--disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
THE machine is a laptop ASUS (in search of increadable; which they will never
find) with Windows 10 (worst OS ever)
[Bug c++/92076] strange strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92076 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-12 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I think you are writing past the array object of buf with the strcpy. We need a full testcase which shows the problem and not just snippets of code.
[Bug c++/92076] strange strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92076 --- Comment #2 from Andrew Pinski --- Try using strncpy instead as you might see the behavior that you are expecting.
[Bug c++/92076] strange strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92076 --- Comment #3 from georg --- Hi Im greatly sorry I now see my obvious stupid bugg. Yr comment was right on str is tpo short, it worked be chance ond luck in the previous lovation which misslead my thinking. Sorry. Can i terminate delete report ??
[Bug c++/92077] New: Multiple independent functions degrades optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077
Bug ID: 92077
Summary: Multiple independent functions degrades optimizations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stinkingmadgod at gmail dot com
Target Milestone: ---
#include
auto f()
{
std::string s1 = "abcdefg";
std::string s2 = "12345678";
return (s1 + s2).size();
}
#ifdef G
auto g()
{
std::string s1 = "abcdefg";
std::string s2 = "1234567";
return (s1 + s2).size();
}
#endif
Discovered on godbolt.org/z/6BTbMk, with target x86_64-linux-gnu built on
20191011. The definition of g() heavily influences assembly for f(). I assume
that this shouldn't happen in any case, hence the report.
AFAIK the optimization on f() is dependent on SSO.
g++ -std=c++2a -O2 gives:
f():
mov eax, 15
ret
g++ -std=c++2a -O2 -DG gives:
f():
pushr12
mov eax, 26213
pushrbp
pushrbx
sub rsp, 96
mov WORD PTR [rsp+20], ax
lea rbx, [rsp+16]
lea rbp, [rsp+48]
mov rsi, rsp
lea rdx, [rsp+32]
lea rdi, [rsp+64]
mov QWORD PTR [rsp], rbx
movabs rax, 4050765991979987505
mov DWORD PTR [rsp+16], 1684234849
mov BYTE PTR [rsp+22], 103
mov QWORD PTR [rsp+8], 7
mov BYTE PTR [rsp+23], 0
mov QWORD PTR [rsp+32], rbp
mov QWORD PTR [rsp+48], rax
mov QWORD PTR [rsp+40], 8
mov BYTE PTR [rsp+56], 0
callstd::__cxx11::basic_string,
std::allocator > std::operator+,
std::allocator >(std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&)
mov rdi, QWORD PTR [rsp+64]
lea rax, [rsp+80]
mov r12, QWORD PTR [rsp+72]
cmp rdi, rax
je .L69
mov rax, QWORD PTR [rsp+80]
lea rsi, [rax+1]
calloperator delete(void*, unsigned long)
.L69:
mov rdi, QWORD PTR [rsp+32]
cmp rdi, rbp
je .L70
mov rax, QWORD PTR [rsp+48]
lea rsi, [rax+1]
calloperator delete(void*, unsigned long)
.L70:
mov rdi, QWORD PTR [rsp]
cmp rdi, rbx
je .L68
mov rax, QWORD PTR [rsp+16]
lea rsi, [rax+1]
calloperator delete(void*, unsigned long)
.L68:
add rsp, 96
mov rax, r12
pop rbx
pop rbp
pop r12
ret
mov rbp, rax
jmp .L72
[Bug c++/92076] strange strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92076 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek --- .
[Bug c++/92077] Multiple independent functions degrades optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077 --- Comment #1 from Andrew Pinski --- Looks like the "independent" function changes inlining decisions. Operator+ is not inlined when G is defined. This might be a heuristic issue of the translational unit growing too big with the inlining.
[Bug c++/92078] New: error: 'struct std::ptr' redeclared with different access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92078
Bug ID: 92078
Summary: error: 'struct std::ptr' redeclared with
different access
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The following code using concepts gives a bogus error:
namespace std
{
template T&& declval();
template
struct iterator_traits;
template
concept iter_has_nested_types = requires {
typename Iter::iterator_category;
typename Iter::value_type;
typename Iter::difference_type;
typename Iter::reference;
};
template
requires (!iter_has_nested_types)
struct iterator_traits
{
private:
template
struct ptr
{ using type = void; };
template requires requires { typename Iter::pointer; }
struct ptr
{ using type = typename Iter::pointer; };
template
requires (!requires { typename Iter::pointer; }
&& requires(Iter& it) { it.operator->(); })
struct ptr
{ using type = decltype(std::declval().operator->()); };
public:
using pointer = typename ptr::type;
};
}
Compiled with trunk and -std=gnu++2a:
access.cc:30:2: error: ‘struct std::ptr’ redeclared with different access
30 | struct ptr
| ^~
[Bug c++/92078] error: 'struct std::ptr' redeclared with different access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92078
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-12
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This is not a redeclaration, it's a specialization. And it doesn't have
different access to the other specialization anyway.
Reduced:
template
struct iterator_traits
{
private:
template
struct ptr
{ };
template requires requires { typename J::X; }
struct ptr
{ };
template
requires (!requires { typename J::X; } && requires { typename J::Y; })
struct ptr
{ };
};
access.cc:17:7: error: ‘struct ptr’ redeclared with different access
17 | struct ptr
| ^~
[Bug middle-end/92063] [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Sat Oct 12 12:21:45 2019
New Revision: 276915
URL: https://gcc.gnu.org/viewcvs?rev=276915&root=gcc&view=rev
Log:
PR middle-end/92063
* tree-eh.c (operation_could_trap_helper_p)
: Return false with *handled = false.
(tree_could_trap_p): For {,VEC_}COND_EXPR return false instead of
recursing on the first operand.
* fold-const.c (simple_operand_p_2): Use generic_expr_could_trap_p
instead of tree_could_trap_p.
* tree-ssa-sccvn.c (vn_nary_may_trap): Formatting fixes.
* gcc.c-torture/compile/pr92063.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr92063.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-ssa-sccvn.c
[Bug middle-end/92063] [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Should be fixed now.
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
--- Comment #7 from paul.richard.thomas at gmail dot com ---
At least it is one of the less harmful bits of code that I have introduced :-)
Yes, it can go.
Thanks
Paul
On Sat, 12 Oct 2019 at 01:18, kargl at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297
>
> --- Comment #6 from kargl at gcc dot gnu.org ---
> (In reply to David Binderman from comment #1)
> > svn blame says:
> >
> > 182796 pault for (args= e->value.function.actual; args; args =
> > args->next)
> > 182796 pault {
> > 182796 pault if (expr == args->expr)
> > 182796 pault expr = args->expr;
> > 182796 pault }
> >
> > so this code looks pretty old.
>
> So, replacing expr = args->expr with gcc_unreachable() finds
> that at gfortran.dg/typebound_operator_[7,8,9,11,21].{f90|f03}
> die with an ICE. Completely removing the section of code
> in question causes no problem with the testsuite.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug c++/92077] Multiple independent functions degrades optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077 --- Comment #2 from Marc Glisse --- It is quite natural for the compiler to inline functions that are only called once (it won't take more space) (although the compiler doesn't actually know that the function isn't also called in another TU) more aggressively than functions called multiple times. If you specify -O3 -finline-limit=300, we do inline and simplify. Now of course it would be nice if the compiler realized that inlining those functions gives a huge benefit in this case. By the way, at -O2, without -DG, we still emit useless definitions for functions _M_mutate and _M_dispose which are not called by f anymore, probably because we remove those calls too late (FRE3).
[Bug c++/91428] Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428 --- Comment #6 from Marek Polacek --- Well, but perhaps the right fix is removing "std::is_constant_evaluated ()" instead?
[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91995 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Sat Oct 12 14:47:34 2019 New Revision: 276916 URL: https://gcc.gnu.org/viewcvs?rev=276916&root=gcc&view=rev Log: PR ada/91995 * sem_ch8.adb (Chain_Use_Clause): Remove second argument in calls to Defining_Entity. * sem_elab.adb (Find_Unit_Entity): Likewise. Deal with N_Subunit here in lieu of in Defining_Entity. * sem_util.ads (Defining_Entity): Remove 2nd and 3th parameters. * sem_util.adb (Defining_Entity): Remove 2nd and 3th parameters, and adjust accordingly. Deal with N_Compilation_Unit. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/sem_ch8.adb trunk/gcc/ada/sem_elab.adb trunk/gcc/ada/sem_util.adb trunk/gcc/ada/sem_util.ads
[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91995 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Sat Oct 12 14:49:21 2019 New Revision: 276917 URL: https://gcc.gnu.org/viewcvs?rev=276917&root=gcc&view=rev Log: PR ada/91995 * sem_ch8.adb (Chain_Use_Clause): Remove second argument in calls to Defining_Entity. * sem_elab.adb (Find_Unit_Entity): Likewise. Deal with N_Subunit here in lieu of in Defining_Entity. * sem_spark.adb (Check_Callable_Body): Likewise. (Check_Package_Body): Likewise. * sem_util.ads (Defining_Entity): Remove 2nd and 3th parameters. * sem_util.adb (Defining_Entity): Remove 2nd and 3th parameters, and adjust accordingly. Deal with N_Compilation_Unit. Modified: branches/gcc-9-branch/gcc/ada/ChangeLog branches/gcc-9-branch/gcc/ada/sem_ch8.adb branches/gcc-9-branch/gcc/ada/sem_elab.adb branches/gcc-9-branch/gcc/ada/sem_spark.adb branches/gcc-9-branch/gcc/ada/sem_util.adb branches/gcc-9-branch/gcc/ada/sem_util.ads
[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91995 --- Comment #7 from Eric Botcazou --- Author: ebotcazou Date: Sat Oct 12 14:50:05 2019 New Revision: 276918 URL: https://gcc.gnu.org/viewcvs?rev=276918&root=gcc&view=rev Log: PR ada/91995 * sem_ch8.adb (Chain_Use_Clause): Remove second argument in calls to Defining_Entity. * sem_elab.adb (Find_Unit_Entity): Likewise. Deal with N_Subunit here in lieu of in Defining_Entity. * sem_spark.adb (Check_Callable_Body): Likewise. (Check_Package_Body): Likewise. * sem_util.ads (Defining_Entity): Remove 2nd and 3th parameters. * sem_util.adb (Defining_Entity): Remove 2nd and 3th parameters, and adjust accordingly. Deal with N_Compilation_Unit. Modified: branches/gcc-8-branch/gcc/ada/ChangeLog branches/gcc-8-branch/gcc/ada/sem_ch8.adb branches/gcc-8-branch/gcc/ada/sem_elab.adb branches/gcc-8-branch/gcc/ada/sem_spark.adb branches/gcc-8-branch/gcc/ada/sem_util.adb branches/gcc-8-branch/gcc/ada/sem_util.ads
[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91995 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Sat Oct 12 14:51:26 2019 New Revision: 276919 URL: https://gcc.gnu.org/viewcvs?rev=276919&root=gcc&view=rev Log: PR ada/91995 * sem_util.ads (Defining_Entity): Remove 2nd and 3th parameters. * sem_util.adb (Defining_Entity): Remove 2nd and 3th parameters, and adjust accordingly. Modified: branches/gcc-7-branch/gcc/ada/ChangeLog branches/gcc-7-branch/gcc/ada/sem_util.adb branches/gcc-7-branch/gcc/ada/sem_util.ads
[Bug c++/92070] [10 regression] -fchecking=2 error: taking address of rvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92070 --- Comment #6 from Dmitry G. Dyachenko --- (In reply to Marek Polacek from comment #5) > Fixed. r267903 FAIL and r267907 PASS for me with original problem -- LLVM-current build Thanks
[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91995 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #9 from Eric Botcazou --- .
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 --- Comment #4 from anlauf at gcc dot gnu.org --- Also adding a blank or a comment after the public makes the ICE go away.
[Bug middle-end/26241] [7/8/9 Regression] None of the IPA passes are documented in passes.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26241 --- Comment #22 from rguenther at suse dot de --- On October 12, 2019 6:20:16 AM GMT+02:00, "egallager at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26241 > >Eric Gallager changed: > > What|Removed |Added > >Summary|[7/8/9/10 Regression] None |[7/8/9 Regression] None of > |of the IPA passes are |the IPA passes are >|documented in passes.texi |documented in passes.texi > >--- Comment #21 from Eric Gallager --- >(In reply to sandra from comment #20) >> Author: sandra >> Date: Thu Oct 10 19:44:26 2019 >> New Revision: 276851 >> >> URL: https://gcc.gnu.org/viewcvs?rev=276851&root=gcc&view=rev >> Log: >> 2019-10-10 Xiong Hu Luo >> Sandra Loosemore >> >> gcc/ >> >> PR middle-end/26241 >> * doc/lto.texi (IPA): Reference to the IPA passes. >> * doc/passes.texi (Pass manager): Add node IPA passes and >>description for each IPA pass. >> >> Modified: >> trunk/gcc/ChangeLog >> trunk/gcc/doc/lto.texi >> trunk/gcc/doc/passes.texi > >So... fixed on trunk... I guess leaving open for backports? No need for that.
[Bug target/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 Iain Sandoe changed: What|Removed |Added Keywords||assemble-failure, ||ice-on-valid-code Target||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-12 Component|c++ |target Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #4 from Iain Sandoe --- this is a target bug, not a c++ one.
[Bug target/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #5 from Iain Sandoe --- Author: iains Date: Sat Oct 12 19:41:50 2019 New Revision: 276926 URL: https://gcc.gnu.org/viewcvs?rev=276926&root=gcc&view=rev Log: [Darwin, machopic 6/n] Fix for 67183 When we're using the LLVM-based assembler (the default on modern Darwin) the ordering of stubs and non-lazy symbol pointers is important. Interleaving the output (current GCC behaviour) leads to crashes which prevents us from building code with symbol stubs. To resolve this, we order the output of stubs and symbol indirections: 1. Any indirections in the data section 2. Symbol stubs. 3. Non-lazy symbol pointers. At present, we still emit LTO sections after these. gcc/ChangeLog: 2019-10-12 Iain Sandoe PR target/67183 * config/darwin.c (machopic_indirection): New field to flag non-lazy-symbol-pointers in the data section. (machopic_indirection_name): Compute if an indirection should appear in the data section. (machopic_output_data_section_indirection): New callback split from machopic_output_indirection. (machopic_output_stub_indirection): Likewise. (machopic_output_indirection): Retain the code for non-lazy symbol pointers in their regular section. (machopic_finish): Use the new callbacks to order the indirection output. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug target/90723] pr88598-2.c segfaults with -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90723 --- Comment #2 from Eric Gallager --- (In reply to prathamesh3492 from comment #1) > Author: prathamesh3492 > Date: Sat Jul 13 08:28:33 2019 > New Revision: 273466 > > URL: https://gcc.gnu.org/viewcvs?rev=273466&root=gcc&view=rev > Log: > 2019-07-15 Prathamesh Kulkarni > > PR target/90723 > * recog.h (temporary_volatile_ok): New class. > * config/aarch64/aarch64.c (aarch64_emit_sve_pred_move): Set > volatile_ok temporarily to true using temporary_volatile_ok. > * expr.c (emit_block_move_via_cpymem): Likewise. > * optabs.c (maybe_legitimize_operand): Likewise. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/aarch64/aarch64.c > trunk/gcc/expr.c > trunk/gcc/optabs.c > trunk/gcc/recog.h Did this fix it?
