[Bug target/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 Eric Gallager changed: What|Removed |Added Component|middle-end |target --- Comment #21 from Eric Gallager --- (In reply to Eric Gallager from comment #20) > Should this really have the middle-end for its component? It seems like this > is more of a target issue... changing component to target
[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 --- Comment #3 from Marc Glisse --- (In reply to 庞庆源 from comment #2) > gcc pmalloc.c -O2 -o ppp -ldl -fno-tree-loop-distribute-patterns > -fno-strict-aliasing > Still not work. -fno-builtin (the malloc+memset -> calloc is not part of loop distribution) > Why I don't see stack overflow if this will trigger function loop calling tail call?
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 Eric Gallager changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at google dot com, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org --- Comment #7 from Eric Gallager --- cc-ing sanitizer maintainers
[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 --- Comment #2 from 庞庆源 --- gcc pmalloc.c -O2 -o ppp -ldl -fno-tree-loop-distribute-patterns -fno-strict-aliasing Still not work. Why I don't see stack overflow if this will trigger function loop calling
[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 --- Comment #1 from Andrew Pinski --- Your implementation of calloc will be calling itself due to the optimization of malloc followed by memset into calloc. You need to use -fno-tree-loop-distribute-patterns for that case since your implementation of malloc calls calloc in some cases. One other thing is you are most likely also violating C aliasing rules; try -fno-strict-aliasing and see if that helps.
[Bug c/90435] New: gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 Bug ID: 90435 Summary: gcc generate infinite loop code when using -O2 or -O3 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pangqingyuan1991 at 163 dot com Target Milestone: --- Created attachment 46342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46342=edit source code I am writing a simple memory allocator now. When I compile it with -O0 or -O1, it works as expected. But when I use -O2 or -O3. The example code seems run into dead loop and never finish. Also try gcc-6.5.0 gcc-7.4.0 gcc-9.1.0 . Since that all gcc versions have such problem. But clang-6 and clang-8 work well as expected. Compiling: gcc pmalloc.c -O2 -o ppp -ldl Running: PMALLOC_SIZE=128M ./ppp
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #10 from Iain Sandoe --- (In reply to David Edelsohn from comment #9) > Changing > > /* Extra stack adjustment for exception handler return. */ > if (crtl->calls_eh_return) > emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, >EH_RETURN_STACKADJ_RTX)); > > is not sufficient for AIX, at least. I am testing an additional change to > the earlier code to load exception handler data. I think it's a non-starter trying to fix Darwin's save_world stuff, so I'm going to stick with disabling tail calls in eh_return fns and then defer anything else until we find a way to remove the save_world stuff.
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #9 from David Edelsohn --- Changing /* Extra stack adjustment for exception handler return. */ if (crtl->calls_eh_return) emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, EH_RETURN_STACKADJ_RTX)); is not sufficient for AIX, at least. I am testing an additional change to the earlier code to load exception handler data.
[Bug tree-optimization/42970] Missed unused function return value elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-05/msg00472.ht ||ml --- Comment #8 from Eric Gallager --- (In reply to Martin Jambor from comment #7) > (In reply to Eric Gallager from comment #6) > > > > Stage 1 has opened again. > > And therefore I have submitted a cleaned-up version for review: > > https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00472.html Cool, thanks! Adding "patch" keyword then.
[Bug lto/90434] New: [regression from 8.x] Incorrect code generation for __builtin_strcmp with LTO and freestanding binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90434
Bug ID: 90434
Summary: [regression from 8.x] Incorrect code generation for
__builtin_strcmp with LTO and freestanding binary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.cooper3 at citrix dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello,
Apologies for this being a complicated bug report, but I think I may need some
help tracking things down further. Nevertheless, I am moderately confident it
is a regression in GCC 9.x, because 8.x works correctly.
I have two versions of GCC built today from the tip of stable branches.
$ PATH=/local/bin/gcc-8.x/bin:$PATH gcc --version
gcc (GCC) 8.3.1 20190511
...
$ PATH=/local/bin/gcc-9.x/bin:$PATH gcc --version
gcc (GCC) 9.1.1 20190511
The 8.x version works correctly, while the 9.x version results in incorrect
code generation, which leads to a crash when executed. Both versions work fine
when LTO is not in use.
The environment is http://xenbits.xen.org/docs/xtf/ which is a set of
microkerenls. As such, they are freestanding builds and linked to a single
final executable, but are standard x86 32bit and 64bit ELF binaries.
Because -ffreestanding disables a whole swathe of builtin optimisations, the
headers locally reinsert the optimisations in the following manner:
int strcmp(const char *s1, const char *s2);
#define strcmp(s1, s2) __builtin_strcmp(s1, s2)
An implementation of strcmp() is also provided for when a real call is emitted
by the builtin:
int (strcmp)(const char *_s1, const char *_s2)
{
unsigned char s1, s2;
do {
s1 = *_s1++;
s2 = *_s2++;
} while ( s1 && s1 == s2 );
return (s1 < s2) ? -1 : (s1 > s2);
}
The problematic test in question calls strcmp() from its main function. With
8.x, the builtin is expanded inline, and (having no callers) the strcmp()
function itself is omitted from the final binary.
With 9.x, the builtin is not expanded inline, and a call to strcmp() is
emitted. strcmp() itself crashes when it first dereferences the second
parameter.
First of all, I found that if I replace the above strcmp() implementation with
this alternative (which I borrowed from the Linux Kernel):
int (strcmp)(const char *_s1, const char *_s2)
{
unsigned char s1, s2;
while ( 1 )
{
s1 = *_s1++;
s2 = *_s2++;
if ( s1 != s2 )
return s1 < s2 ? -1 : 1;
if ( !s1 )
break;
}
return 0;
}
then 9.x *does* expand the builtin inline, and the strcmp() function itself is
omitted from the final binary. This binary also executes correctly.
Therefore, something is clearly inspecting the content of my locally provided
strcmp() function and deciding that it can't expand the builtin inline.
However, I'm not sure what it is checking for, because AFAICT, the ABI of those
two variations is identical.
That on its own would only cause an efficiently problem, not a correctness
problem.
When inspecting the disassembly of the bad binary, I see that strcmp() has its
parameters passed in registers rather than on the stack. AFAICT, the value of
the _s1 parameter is always correct, while the value of _s2 seems to be less
than 256 (possibly a single char?). The crash occurs because the deference of
_s2 hits the zero page.
As a result, it is clear that the strcmp() function has been compiled with a
non-standard ABI. AFAICT, the calling code in main() does conform to the
expected ABI, by passing the parameters on the stack.
Therefore, I wonder whether the code actually emitted for strcmp() was supposed
to be a specialised version (strcmp.isra.$foo perhaps, or something else),
which actually got called with the original ABI.
Anyway - that is as far as I've got debugging. Can anyone suggest further
steps to help narrow this down?
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 --- Comment #11 from Iain Sandoe --- Author: iains Date: Sat May 11 20:19:31 2019 New Revision: 271098 URL: https://gcc.gnu.org/viewcvs?rev=271098=gcc=rev Log: fixincludes - fix PR90379 One should not provide test_text for wrap style fixes this was causing the test to fail. No change to the actual fix. 2019-05-11 Iain Sandoe PR target/90379 PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #95 from Iain Sandoe --- Author: iains Date: Sat May 11 20:19:31 2019 New Revision: 271098 URL: https://gcc.gnu.org/viewcvs?rev=271098=gcc=rev Log: fixincludes - fix PR90379 One should not provide test_text for wrap style fixes this was causing the test to fail. No change to the actual fix. 2019-05-11 Iain Sandoe PR target/90379 PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 fiesh at zefix dot tv changed: What|Removed |Added CC||fiesh at zefix dot tv --- Comment #15 from fiesh at zefix dot tv --- This seems to have been solved entirely with the release of 9.1! So it should remain closed. (8.3 is still broken)
[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90426
--- Comment #5 from Mateusz Pusz ---
(In reply to Mateusz Pusz from comment #3)
> (In reply to Marek Polacek from comment #1)
> > This compiles if I use {} instead of ():
> >
> > struct gram : unit {};
>
> (In reply to Marek Polacek from comment #2)
> > I think this is invalid. [temp.arg]p2:
> > "In a template-argument, an ambiguity between a type-id and an expression is
> > resolved to a type-id, regardless of the form of the corresponding
> > template-parameter."
> >
> > template
> > struct S { };
> >
> > struct R { };
> >
> > void
> > g (void)
> > {
> > S s; // template argument treated as function type
> > S s2;
> > S s3; // template argument treated as function type
> > S s4;
> > }
>
> Please note that all of the following compiles fine and is not treated as a
> function type (most vexing parse)
>
> constexpr auto r1(ratio(std::milli()));
> constexpr auto r2(ratio(std::milli()));
> constexpr ratio r3(std::milli());
My bad, that actually is a most vexing parse issue. Sorry!
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #8 from Segher Boessenkool --- It also fails all over on powerpc-linux. Pretty much all targets just do something like /* Extra stack adjustment for exception handler return. */ if (crtl->calls_eh_return) emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, EH_RETURN_STACKADJ_RTX)); /* Now we can return. */ emit_jump_insn (gen_simple_return ()); A fix should be target-independent, or it should fix all targets.
[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90426
--- Comment #4 from Mateusz Pusz ---
(In reply to Marek Polacek from comment #1)
> This compiles if I use {} instead of ():
>
> struct gram : unit {};
I know that it compiles fine in the following cases:
struct gram : unit {};
struct gram : unit {}; // not treated as a function type
struct gram : unit {};
So the only one lacking is:
struct gram : unit {};
[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90426
--- Comment #3 from Mateusz Pusz ---
(In reply to Marek Polacek from comment #1)
> This compiles if I use {} instead of ():
>
> struct gram : unit {};
(In reply to Marek Polacek from comment #2)
> I think this is invalid. [temp.arg]p2:
> "In a template-argument, an ambiguity between a type-id and an expression is
> resolved to a type-id, regardless of the form of the corresponding
> template-parameter."
>
> template
> struct S { };
>
> struct R { };
>
> void
> g (void)
> {
> S s; // template argument treated as function type
> S s2;
> S s3; // template argument treated as function type
> S s4;
> }
Please note that all of the following compiles fine and is not treated as a
function type (most vexing parse)
constexpr auto r1(ratio(std::milli()));
constexpr auto r2(ratio(std::milli()));
constexpr ratio r3(std::milli());
[Bug tree-optimization/42970] Missed unused function return value elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970 --- Comment #7 from Martin Jambor --- (In reply to Eric Gallager from comment #6) > > Stage 1 has opened again. And therefore I have submitted a cleaned-up version for review: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00472.html
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #13 from Martin Sebor ---
I had started by doing that but gave up when I noticed that there are lots of
them, some like this:
if (TREE_CODE (expr) == REALPART_EXPR
|| TREE_CODE (expr) == IMAGPART_EXPR
|| TREE_CODE (expr) == BIT_FIELD_REF)
{
tree op = TREE_OPERAND (expr, 0);
if (!is_gimple_reg_type (TREE_TYPE (expr)))
{
error ("non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR");
return true;
}
some like this:
case VEC_UNPACK_HI_EXPR:
case VEC_UNPACK_LO_EXPR:
case VEC_UNPACK_FLOAT_HI_EXPR:
case VEC_UNPACK_FLOAT_LO_EXPR:
case VEC_UNPACK_FIX_TRUNC_HI_EXPR:
case VEC_UNPACK_FIX_TRUNC_LO_EXPR:
...
error ("type mismatch in vector unpack expression");
that avoid mentioning the exact code altogether, or like this:
case LSHIFT_EXPR:
case RSHIFT_EXPR:
case LROTATE_EXPR:
case RROTATE_EXPR:
...
error ("type mismatch in shift expression");
and some even that "lie" for the sake of brevity. It would be nice to always
mention the exact code.
But I can save the result of get_tree_code_name (rhs_code) and use that instead
of calling it repeatedly. (My initial approach was to add a new directive to
the generic pretty-printer but, sadly, get_tree_code_name is defined in tree.c
and not available there so I'd have had to duplicate the directive code for
each front-end and for the middle-end. That seems like too much hassle.)
[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81058 --- Comment #8 from Iain Sandoe --- Author: iains Date: Sat May 11 15:05:58 2019 New Revision: 271097 URL: https://gcc.gnu.org/viewcvs?rev=271097=gcc=rev Log: testsuite, darwin] Fix PR81058. The tests fail because Darwin indirects common accesses which causes different codegen and the mismatch in output. Placing the vars in regular .data section fixes that. gcc/testsuite/ 2019-05-11 Iain Sandoe PR testsuite/81058 * gcc.target/i386/avx512bw-vpmovswb-1.c: Use regular data section for variables on Darwin, rather than common. * gcc.target/i386/avx512bw-vpmovuswb-1.c: Likewise. * gcc.target/i386/avx512bw-vpmovwb-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx512bw-vpmovswb-1.c trunk/gcc/testsuite/gcc.target/i386/avx512bw-vpmovuswb-1.c trunk/gcc/testsuite/gcc.target/i386/avx512bw-vpmovwb-1.c
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 --- Comment #10 from Iain Sandoe --- (In reply to marc from comment #9) > The patch does no longer apply to current gcc-9-branch, which, however, > still has the problem. The_Atomic stuff is easy to spot, though, and I can > confirm this fixes it for me, too (though I guess it's a hotfix, and nothing > mergeable, otherwise it would already be merged?). The usual process is to apply to trunk and then backport to any relevant active branches. I will get to it hopefully during this weekend (it will then appear in 9.2 when that's released but be available from 9 branch snapshots in the meantime).
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 marc at kdab dot com changed: What|Removed |Added CC||marc at kdab dot com --- Comment #9 from marc at kdab dot com --- The patch does no longer apply to current gcc-9-branch, which, however, still has the problem. The_Atomic stuff is easy to spot, though, and I can confirm this fixes it for me, too (though I guess it's a hotfix, and nothing mergeable, otherwise it would already be merged?).
[Bug fortran/61968] ICE (assembly failure) due to wrongly generating a vtable for TYPE(*) / BT_ASSUMED_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61968 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Thomas Koenig --- Fixed on trunk, closing.
[Bug tree-optimization/90433] New: POINTER_DIFF_EXPR in vectorizer prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433
Bug ID: 90433
Summary: POINTER_DIFF_EXPR in vectorizer prologue
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I am picking a random code that gets vectorized to illustrate the issue
#include
#include
#include
inline void* operator new(std::size_t n){return malloc(n);}
inline void operator delete(void*p){free(p);}
typedef std::unique_ptr T;
typedef std::vector V;
void f(V){v.reserve(1024);}
Compiling with -O3 on x86_64, the vectorizer produces
[local count: 354334802]:
_9 = MEM[(struct unique_ptr * *)v_2(D) + 8B];
_10 = _9 - _4;
_24 = malloc (8192);
if (_4 == _9)
goto ; [11.00%]
else
goto ; [89.00%]
[local count: 315357974]:
_26 = (unsigned long) _9;
_16 = (unsigned long) _4;
_13 = _26 - _16;
_23 = _13 + 18446744073709551608;
_11 = _23 /[ex] 8;
_3 = _11 & 2305843009213693948;
_38 = _3 != 0;
_39 = _4 + 15;
_40 = _39 - _24;
_41 = (sizetype) _40;
_42 = _41 > 30;
_43 = _38 & _42;
if (_43 != 0)
goto ; [80.00%]
else
goto ; [20.00%]
[local count: 252286381]:
_55 = (unsigned long) _9;
_56 = (unsigned long) _4;
_57 = _55 - _56;
_58 = _57 + 18446744073709551608;
_59 = _58 /[ex] 8;
_60 = _59 & 2305843009213693951;
niters.75_54 = _60 + 1;
bnd.76_71 = niters.75_54 >> 1;
Note the lines marked with stars. To compute the size of the memory region, it
casts the pointers to unsigned long and subtracts those, whereas it could
perfectly well use POINTER_DIFF_EXPR. On the other hand, (for the aliasing
check?) it subtracts _39 and _24 which are completely independent pointers (one
was freshly returned by malloc) using POINTER_DIFF_EXPR, while IIRC this is
only supposed to be used for subtraction of pointers into the same
object/region.
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed for 8.4 and 9.2
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Sat May 11 11:38:51 2019 New Revision: 271095 URL: https://gcc.gnu.org/viewcvs?rev=271095=gcc=rev Log: PR libstdc++/81266 fix std::thread::native_handle_type test The test uses remove_pointer because in most cases native_handle_type is a pointer to the actual type that the C++ class contains. However, for std::thread, native_handle_type is the same type as the type contained in std::thread, and so remove_pointer is not needed. On targets where pthread_t is a pointer type remove_pointer is not a no-op, instead it transforms pthread_t and causes the test to fail. The fix is to not apply remove_pointer when testing std::thread. Backport from mainline 2019-05-10 Jonathan Wakely PR libstdc++/81266 * testsuite/util/thread/all.h: Do not use remove_pointer for std::thread::native_handle_type. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/testsuite/util/thread/all.h
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Sat May 11 11:35:59 2019 New Revision: 271094 URL: https://gcc.gnu.org/viewcvs?rev=271094=gcc=rev Log: PR libstdc++/81266 fix std::thread::native_handle_type test The test uses remove_pointer because in most cases native_handle_type is a pointer to the actual type that the C++ class contains. However, for std::thread, native_handle_type is the same type as the type contained in std::thread, and so remove_pointer is not needed. On targets where pthread_t is a pointer type remove_pointer is not a no-op, instead it transforms pthread_t and causes the test to fail. The fix is to not apply remove_pointer when testing std::thread. Backport from mainline 2019-05-10 Jonathan Wakely PR libstdc++/81266 * testsuite/util/thread/all.h: Do not use remove_pointer for std::thread::native_handle_type. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/testsuite/util/thread/all.h
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #16 from Jakub Jelinek --- Author: jakub Date: Sat May 11 09:33:22 2019 New Revision: 271093 URL: https://gcc.gnu.org/viewcvs?rev=271093=gcc=rev Log: PR c++/59813 * config/aarch64/aarch64.c (aarch64_expand_epilogue): Don't add EH_RETURN_STACKADJ_RTX to sp in sibcall epilogues. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > As in Fortran 2008, internal and dummy procedures are allowed only in > procedure pointer assignments, but not in proc-ptr initialization. The following valid program works around this restriction in the Fortran standard: implicit none interface function f() result(i) integer i end function end interface procedure(f), pointer :: g g=>h contains function h() result(j) integer j j=1 end function end I'll close this PR as invalid, if you don't mind ...
[Bug fortran/90355] Uninitialized read in gfortran.dg/ISO_Fortran_binding_4.f90 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90355 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on trunk and 9-branch. Thanks for the report Paul
[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Paul Thomas --- Fixed on trunk and 9-branch. Thanks for the report Paul
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |8.4 --- Comment #6 from Iain Sandoe --- Fixed on trunk, needed on 9 and 8.
[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk and 9-branch. Thanks for the report Paul
[Bug fortran/90355] Uninitialized read in gfortran.dg/ISO_Fortran_binding_4.f90 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90355 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat May 11 07:49:52 2019 New Revision: 271090 URL: https://gcc.gnu.org/viewcvs?rev=271090=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352 --- Comment #9 from Paul Thomas --- Author: pault Date: Sat May 11 07:49:52 2019 New Revision: 271090 URL: https://gcc.gnu.org/viewcvs?rev=271090=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 --- Comment #5 from Paul Thomas --- Author: pault Date: Sat May 11 07:49:52 2019 New Revision: 271090 URL: https://gcc.gnu.org/viewcvs?rev=271090=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.c branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_12.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90
[Bug fortran/90352] [9/10 Regression] ICE on BIND(C) subroutine with characters with len /= 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352 --- Comment #8 from Paul Thomas --- Author: pault Date: Sat May 11 07:47:32 2019 New Revision: 271089 URL: https://gcc.gnu.org/viewcvs?rev=271089=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * trans-decl.c (convert_CFI_desc): Test that the dummy is present before doing any of the conversions. PR fortran/90352 * decl.c (gfc_verify_c_interop_param): Restore the error for charlen > 1 actual arguments passed to bind(C) procs. Clean up trailing white space. PR fortran/90355 * trans-array.c (gfc_trans_create_temp_array): Set the 'span' field to the element length for all types. (gfc_conv_expr_descriptor): The force_no_tmp flag is used to prevent temporary creation, especially for substrings. * trans-decl.c (gfc_trans_deferred_vars): Rather than assert that the backend decl for the string length is non-null, use it as a condition before calling gfc_trans_vla_type_sizes. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp' is set before calling gfc_conv_expr_descriptor. * trans.c (get_array_span): Move the code for extracting 'span' from gfc_build_array_ref to this function. This is specific to descriptors that are component and indirect references. * trans.h : Add the force_no_tmp flag bitfield to gfc_se. 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/fortran/trans-array.c branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/fortran/trans-expr.c branches/gcc-9-branch/gcc/fortran/trans.c branches/gcc-9-branch/gcc/fortran/trans.h branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/assign_10.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/90355] Uninitialized read in gfortran.dg/ISO_Fortran_binding_4.f90 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90355 --- Comment #3 from Paul Thomas --- Author: pault Date: Sat May 11 07:47:32 2019 New Revision: 271089 URL: https://gcc.gnu.org/viewcvs?rev=271089=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * trans-decl.c (convert_CFI_desc): Test that the dummy is present before doing any of the conversions. PR fortran/90352 * decl.c (gfc_verify_c_interop_param): Restore the error for charlen > 1 actual arguments passed to bind(C) procs. Clean up trailing white space. PR fortran/90355 * trans-array.c (gfc_trans_create_temp_array): Set the 'span' field to the element length for all types. (gfc_conv_expr_descriptor): The force_no_tmp flag is used to prevent temporary creation, especially for substrings. * trans-decl.c (gfc_trans_deferred_vars): Rather than assert that the backend decl for the string length is non-null, use it as a condition before calling gfc_trans_vla_type_sizes. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp' is set before calling gfc_conv_expr_descriptor. * trans.c (get_array_span): Move the code for extracting 'span' from gfc_build_array_ref to this function. This is specific to descriptors that are component and indirect references. * trans.h : Add the force_no_tmp flag bitfield to gfc_se. 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/fortran/trans-array.c branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/fortran/trans-expr.c branches/gcc-9-branch/gcc/fortran/trans.c branches/gcc-9-branch/gcc/fortran/trans.h branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/assign_10.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 --- Comment #4 from Paul Thomas --- Author: pault Date: Sat May 11 07:47:32 2019 New Revision: 271089 URL: https://gcc.gnu.org/viewcvs?rev=271089=gcc=rev Log: 2019-05-11 Paul Thomas PR fortran/90093 * trans-decl.c (convert_CFI_desc): Test that the dummy is present before doing any of the conversions. PR fortran/90352 * decl.c (gfc_verify_c_interop_param): Restore the error for charlen > 1 actual arguments passed to bind(C) procs. Clean up trailing white space. PR fortran/90355 * trans-array.c (gfc_trans_create_temp_array): Set the 'span' field to the element length for all types. (gfc_conv_expr_descriptor): The force_no_tmp flag is used to prevent temporary creation, especially for substrings. * trans-decl.c (gfc_trans_deferred_vars): Rather than assert that the backend decl for the string length is non-null, use it as a condition before calling gfc_trans_vla_type_sizes. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): 'force_no_tmp' is set before calling gfc_conv_expr_descriptor. * trans.c (get_array_span): Move the code for extracting 'span' from gfc_build_array_ref to this function. This is specific to descriptors that are component and indirect references. * trans.h : Add the force_no_tmp flag bitfield to gfc_se. 2019-05-11 Paul Thomas PR fortran/90093 * gfortran.dg/ISO_Fortran_binding_12.f90: New test. * gfortran.dg/ISO_Fortran_binding_12.c: Supplementary code. PR fortran/90352 * gfortran.dg/iso_c_binding_char_1.f90: New test. PR fortran/90355 * gfortran.dg/ISO_Fortran_binding_4.f90: Add 'substr' to test the direct passing of substrings as descriptors to bind(C). * gfortran.dg/assign_10.f90: Increase the tree_dump count of 'atmp' to account for the setting of the 'span' field. * gfortran.dg/transpose_optimization_2.f90: Ditto. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/fortran/trans-array.c branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/fortran/trans-expr.c branches/gcc-9-branch/gcc/fortran/trans.c branches/gcc-9-branch/gcc/fortran/trans.h branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_4.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/assign_10.f90 branches/gcc-9-branch/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 --- Comment #3 from janus at gcc dot gnu.org --- Also I have just looked into the Fortran 2018 standard, and I don't think the situation has changed there: R1518 initial-proc-target is procedure-name C1519 (R1518) The procedure-name shall be the name of a nonelemental external or module procedure, or a specific intrinsic function listed in Table 16.2. As in Fortran 2008, internal and dummy procedures are allowed only in procedure pointer assignments, but not in proc-ptr initialization.
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 --- Comment #2 from janus at gcc dot gnu.org --- I think the test case is actually invalid (at least wrt Fortran 2008), see PR 85537 comment 18 (and 20).
[Bug pch/90326] Using any precompiled header breaks definition of FLT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326 Alex Smith changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alex Smith --- Confirmed that fixes it (built and test 9.1.0 from source without/with that patch applied). Thanks!
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #12 from rguenther at suse dot de ---
On May 10, 2019 10:34:03 PM GMT+02:00, "msebor at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
>
>Martin Sebor changed:
>
> What|Removed |Added
>
> Status|NEW |ASSIGNED
> Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
>
>--- Comment #11 from Martin Sebor ---
>I'm replacing all the tree codes with %qs and get_tree_code_name
>(TREE_CODE
>(expr)), like so:
>
>@@ -3072,13 +3073,15 @@ verify_types_in_gimple_reference (tree expr,
>bool
>requir
>e_lvalue)
>size))
>{
> error ("mode size of non-integral result does not "
>-"match field size of BIT_FIELD_REF");
>+"match field size of %qs",
>+get_tree_code_name (TREE_CODE (expr)));
> return true;
>}
> if (INTEGRAL_TYPE_P (TREE_TYPE (op))
> && !type_has_mode_precision_p (TREE_TYPE (op)))
>{
>- error ("BIT_FIELD_REF of non-mode-precision operand");
>+ error ("%qs of non-mode-precision operand",
>+get_tree_code_name (TREE_CODE (expr)));
> return true;
>}
> if (!AGGREGATE_TYPE_P (TREE_TYPE (op))
That looks excessive for code size. Why not just quote the names appropriately?
