[Bug middle-end/88518] Function call defeats -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88518 --- Comment #4 from Eric Gallager --- Note that if h() has __attribute__((pure)) or __attribute__((const)) on it, you then get the -Wuninitialized warning as expected. Of course, then you also get a warning from -Wattributes about pure or const being used on a function returning void, too...
[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665 --- Comment #6 from Eric Gallager --- Note that clang has __attribute__((flag_enum)): https://clang.llvm.org/docs/AttributeReference.html#flag-enum
[Bug c++/90725] implicitly used 'this' not diagnosed in static member fn declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90725 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- Actually, this is INVALID. And it's even tested by my g++.dg/cpp0x/this1.C.
[Bug d/90603] ICE in functionParameters, at d/dmd/expression.c:1553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90603 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272366.
[Bug d/90603] ICE in functionParameters, at d/dmd/expression.c:1553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90603 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 22:50:16 2019 New Revision: 272366 URL: https://gcc.gnu.org/viewcvs?rev=272366=gcc=rev Log: PR d/90603 d/dmd: Merge upstream dmd 792f0fdf2 Fixes segmentation fault in functionParameters, and other related semantic bugs in forward or recursively referenced declarations. Reviewed-on: https://github.com/dlang/dmd/pull/10046 Added: trunk/gcc/testsuite/gdc.test/compilable/imports/test16214b.d trunk/gcc/testsuite/gdc.test/compilable/test16214a.d trunk/gcc/testsuite/gdc.test/fail_compilation/b15875.d trunk/gcc/testsuite/gdc.test/fail_compilation/b17285.d trunk/gcc/testsuite/gdc.test/fail_compilation/b19691.d trunk/gcc/testsuite/gdc.test/fail_compilation/b19691e.d trunk/gcc/testsuite/gdc.test/fail_compilation/b19717.d trunk/gcc/testsuite/gdc.test/fail_compilation/b19717a.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/dclass.c trunk/gcc/d/dmd/declaration.c trunk/gcc/d/dmd/denum.c trunk/gcc/d/dmd/dimport.c trunk/gcc/d/dmd/dinterpret.c trunk/gcc/d/dmd/dstruct.c trunk/gcc/d/dmd/dtemplate.c trunk/gcc/d/dmd/expression.c trunk/gcc/d/dmd/expressionsem.c trunk/gcc/d/dmd/func.c trunk/gcc/d/dmd/mtype.c trunk/gcc/d/dmd/optimize.c trunk/gcc/d/dmd/statement.c trunk/gcc/d/dmd/statementsem.c trunk/gcc/d/dmd/traits.c
[Bug c/88000] Warn when different local vars regs order may produce different and so unsupported code [-Wasm-register-var]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000 --- Comment #6 from Dominik Czarnota --- (In reply to Eric Gallager from comment #5) > Reopening to confirm the part about this warning request at least Yay, thanks. I am happy someone cares about this. It is good to make it less likely that the users shoot themselves in the foot.
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #32 from John David Anglin --- Author: danglin Date: Sun Jun 16 21:49:19 2019 New Revision: 272364 URL: https://gcc.gnu.org/viewcvs?rev=272364=gcc=rev Log: PR middle-end/64242 * config/pa/pa.md (nonlocal_goto): Restore frame pointer last. Add frame clobbers and schedule block. (builtin_longjmp): Likewise. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/pa/pa.md
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #31 from John David Anglin --- Author: danglin Date: Sun Jun 16 21:46:47 2019 New Revision: 272363 URL: https://gcc.gnu.org/viewcvs?rev=272363=gcc=rev Log: PR middle-end/64242 * config/pa/pa.md (nonlocal_goto): Restore frame pointer last. Add frame clobbers and schedule block. (builtin_longjmp): Likewise. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/pa/pa.md
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #30 from John David Anglin --- Author: danglin Date: Sun Jun 16 21:44:08 2019 New Revision: 272362 URL: https://gcc.gnu.org/viewcvs?rev=272362=gcc=rev Log: PR middle-end/64242 * config/pa/pa.md (nonlocal_goto): Restore frame pointer last. Add frame clobbers and schedule block. (builtin_longjmp): Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/pa/pa.md
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242 --- Comment #29 from John David Anglin --- Author: danglin Date: Sun Jun 16 21:27:14 2019 New Revision: 272361 URL: https://gcc.gnu.org/viewcvs?rev=272361=gcc=rev Log: PR middle-end/64242 * config/pa/pa.md (nonlocal_goto): Restore frame pointer last. Add frame clobbers and schedule block. (builtin_longjmp): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.md
[Bug libquadmath/58327] Problem of quadmath in connection with SDL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58327 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-16 CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=51007 Ever confirmed|0 |1 --- Comment #6 from Eric Gallager --- (In reply to Kai Tietz from comment #5) > This sounds a bit like an issue with OP-specific invocation of ld. How are > you invoke the linker? WAITING on a reply to this
[Bug objc++/85335] Possible misuse of 'lang_GNU_OBJC' in 'default_floatn_builtin_p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85335
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #1 from Eric Gallager ---
(In reply to avshash from comment #0)
> In function 'default_floatn_builtin_p' at 'gcc/targhooks.c'.
> Using the lang_GNU_OBJC query that returns TRUE when the language is either
> Objective C, or Objective C++ (documentation in 'langhooks.c' implementation
> is wrong).
> According to documentation, the test is for Objective C only.
> Need to either clariffy the documentation, or replacte the function call with
> "(strcmp ("GNU Objective-C", lang_hooks.name) == 0)"
Could you give a bit more context? Why is this an issue?
[Bug target/90811] [nvptx] ptxas error on OpenMP offloaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #13 from Christophe Lyon --- Hi, Commit r272181 (#c12) is causing regressions on arm: gcc.dg/store_merging_27.c scan-tree-dump store-merging "New sequence of [12] stores to replace old one of 3 stores" gcc.dg/store_merging_28.c scan-tree-dump-times store-merging "New sequence of [24] stores to replace old one of 6 stores" 1 gcc.dg/store_merging_29.c scan-tree-dump store-merging "New sequence of [34] stores to replace old one of 6 stores" gfortran.dg/pr45636.f90 -O scan-tree-dump-times forwprop2 "memset" 0 on arm-none-linux-gnueabi[hf] --with-cpu=cortex-a9
[Bug c++/60742] ill-formed declarator (array) in selection statement not caught appropriately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60742 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Fixed by r260482.
[Bug sanitizer/89832] confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 --- Comment #8 from Martin Liška --- Patch was merged in upstream.
[Bug fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 --- Comment #2 from Janne Blomqvist --- libgfortran/runtime/memory.c (xmallocarray) has been fixed for GCC 10, frontend part still todo.
[Bug c++/83820] No diagnostic issued for noreturn attribute specifier with an argument list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83820 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00901.html
[Bug d/90893] ODR violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893 --- Comment #1 from Iain Buclaw --- libcall_type is internal to d/runtime.cc, so I'm fine with just prefixing it with d_.
[Bug fortran/90890] segfault on LHS memory reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890 --- Comment #5 from Steve Kargl --- On Sun, Jun 16, 2019 at 04:03:50PM +, bharat.mahajan at hotmail dot com wrote: > > Ok I agree that 'a' is undefined in this case. But that was not my concern in > the original submission. To again clarify what my concern is, > > If the following program fails with segfault because 'a' is undefined: > > program test > implicit none > real, dimension(:), allocatable :: a > integer :: b > a = [a, 2.0] > b = 100 > print *, a > end program test > > then why the following program works and prints "2.0" on screen?? You got lucky. You gave the compiler invalid code. It can do anything with the code (including giving you a result that you may expect). > program test > implicit none > real, dimension(:), allocatable :: a > a = [a, 2.0] > print *, a > end program test > > This is just very unusual to me because 'b' is unrelated to 'a' and 'a' is > undefined in both programs. We should see segfault in both cases to be > consistent but I am seeing that the 2nd programs works and prints "2.0" on > windows machine with MinGW-w64's gfortran-8. I checked it on gfortran-8 on > Ubuntu and it segfaults in both cases, so this behavior is may be specific to > MingW-w64 project only. > > If you are saying standard does not say any thing in this regard and if you > use > 'a' in this manner, the behavior is undefined. So this behavior of sometimes > it > works and sometimes not is ok, I hear you. The Fortran standard says plenty. To paraphrase, a program(mer) shall not reference an undefined variable. There are very few exceptions (like 2). The only place an unallocate allocatable entity can be referenced is as the argument to the ALLOCATED() intrinsic proceduce. The other exception is that an unassociated POINTER can be referenced in the ASSOCIATED() intrinsic procedure. If the Fortran standard had a requirement that a compiler must detect and report the above invalid program, then the Fortran standard would contain a numbered constraint. There isn't a number constraint. F2018 contains 5.4.10 Allocatable variables The allocation status of an allocatable variable is either allocated or unallocated. An allocatable variable becomes allocated as described in 9.7.1.3. It becomes unallocated as described in 9.7.3.2. An unallocated allocatable variable shall not be referenced or defined. > To be honest, computer science is not my area of expertise and I have been > doing Fortran programming part-time since February 2019, so see for yourself > if > I am making any sense here!! I'm a physicist with an area of expertise in is underwater acoustic. In fact, I think that you'll find that none of the usual contributors to gfortran are computer scientist.
[Bug d/90893] New: ODR violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90893 Bug ID: 90893 Summary: ODR violation Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- LTO bootstrap warns on ../../gcc/d/runtime.cc:37:6: warning: type ‘libcall_type’ violates the C++ One Definition Rule [-Wodr] 37 | enum libcall_type | ^ ../../gcc/rtl.h:4112:6: note: an enum with different value name is defined in another translation unit 4112 | enum libcall_type | ^ which is legitimate warning - there are two unrelated enums libcall_type and one should be renamed or put into a namespace.
[Bug tree-optimization/90892] New: [9/10 regression] -O2 miscompiles __builtin_strncmp with string containing '\0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90892
Bug ID: 90892
Summary: [9/10 regression] -O2 miscompiles __builtin_strncmp
with string containing '\0'
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
It looks like doing things like __builtin_strncmp(someString, "A\0", 2) does an
out of bound comparison (ie comparing 3 chars instead of 2), and leads to wrong
behavior. It happens with gcc 9.1.1 and apparently 10 as well (checked on
godbolt: https://godbolt.org/z/CDvkRs)
> cat test.c
volatile char a[3] = { 'A', '\0', 42 };
int main()
{
char b[3] = {a[0], a[1], a[2]};
return __builtin_strncmp(b, "A\0", 2);
}
> gcc -O2 -o test test.c
> ./test && echo 'OK!!!' || echo 'KO...'
KO...
I would expect that it always returns "OK!!!" no matter which optimization
level is used. -O0 and -O1 are working fine. gcc 8 is happy with this at all
optimization levels. I hope using strings like "A\0" is not UB.
Cheers,
Romain
[Bug fortran/90890] segfault on LHS memory reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890 --- Comment #4 from Bharat Mahajan --- (In reply to Steve Kargl from comment #3) > On Sat, Jun 15, 2019 at 11:08:43PM +, bharat.mahajan at hotmail dot com > wrote: > > > > I forgot to mention that code runs with no issues with ifort. Second, then > > why > > the following code works with gfortran? > > The Fortran standard does not require a Fortran processor (i.e., > the compiler) to detect and report that you are using an undefined > entity. > > > program test > > implicit none > > real, dimension(:), allocatable :: a > > integer :: b > > a = [a, 2.0] > > What value does 'a' have on the right side of the above > expression? > > The correct way to write the above would have either > been to assign something to 'a' prior to using on the > RHS above or writing > >if (allocated(a)) a = [a, 2.0] > > > !b = -100 > > end program test > > --- > > > > I am not sure I would say 'a' is not defined. > > The Fortran standard decides what is defined and undefined. > > From F2018 > >19.6.2 Variables that are always defined > >Zero-sized arrays and zero-length strings are always defined. > >19.6.3 Variables that are initially defined > >The following variables are initially defined: > > (1) variables specified to have initial values by DATA statements; > (2) variables specified to have initial values by type declaration > statements; > (3) nonpointer default-initialized subcomponents of saved variables > that do not have the ALLOCATABLE or POINTER attribute; > (4) pointers specified to be initially associated with a variable > that is initially defined; > (5) variables that are always defined; > (6) variables with the BIND attribute that are initialized by means > other than Fortran. > >19.6.4 Variables that are initially undefined > >Variables that are not initially defined are initially undefined. > > Your 'a' is undefined. Ok I agree that 'a' is undefined in this case. But that was not my concern in the original submission. To again clarify what my concern is, If the following program fails with segfault because 'a' is undefined: program test implicit none real, dimension(:), allocatable :: a integer :: b a = [a, 2.0] b = 100 print *, a end program test then why the following program works and prints "2.0" on screen?? program test implicit none real, dimension(:), allocatable :: a a = [a, 2.0] print *, a end program test This is just very unusual to me because 'b' is unrelated to 'a' and 'a' is undefined in both programs. We should see segfault in both cases to be consistent but I am seeing that the 2nd programs works and prints "2.0" on windows machine with MinGW-w64's gfortran-8. I checked it on gfortran-8 on Ubuntu and it segfaults in both cases, so this behavior is may be specific to MingW-w64 project only. If you are saying standard does not say any thing in this regard and if you use 'a' in this manner, the behavior is undefined. So this behavior of sometimes it works and sometimes not is ok, I hear you. However, in my personal opinion if a user tries to use an allocatable array in the following manner: real, dimension(:), allocatable :: a a = [a, 2.0] the compiler (or processor) should see that 'a' is not defined/allocated yet so just allocate the storage for only 1 real in this case. I think the standard says that compiler will do automatic reallocation based on RHS expression and 'a' on RHS can be seen as having 0 size. This is what ifort is doing and from a programmer's perspective we don't have to deal with this ugly piece of code every time in a loop: if (.NOT. allocated(a)) then a = 2.0 else a = [a, 2.0] end if I am not sure the gfortran strategy of forcing the programmer to define 'a' first before using it in 'a=[a,2.0]' helps in catching any bugs. And it defeats the purpose of having the convenience of automatic reallocation a little. To be honest, computer science is not my area of expertise and I have been doing Fortran programming part-time since February 2019, so see for yourself if I am making any sense here!!
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 --- Comment #7 from Jan Hubicka --- Created attachment 46490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46490=edit dumps
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 --- Comment #6 from Eric Botcazou --- > Perhaps it may make sense to compile the non-compliant units with > -fno-lto so we stay safe? I'll have a look, but that's probably overkill. > (while working on alias oracle I would like to be able to LTO test Ada > since it has some specialities in this area) Makes sense of course. The gnat.dg testsuite should already contain testcases for the modifications made to the middle-end in order to help Ada.
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 --- Comment #5 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 > > Eric Botcazou changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2019-06-16 > Ever confirmed|0 |1 > > --- Comment #4 from Eric Botcazou --- > > BTW are all those type mismatch waning actually correct? I was looking into > > the Ada manual for C compatibility and i think we implement it correctly, so > > there should be no mismatches if language standard is followed. It is easily > > possible that I missed something important. > > Most warnings are in units implementing the low-level support of the language, > in particular exceptions, so this is not pure Ada. A few others could be > fixed. Perhaps it may make sense to compile the non-compliant units with -fno-lto so we stay safe? > > > BTW -fchecking=0 lets me to finish the build, but later I get wrong -fPIC > > for ada runtime, which also seem new. > > You probably need to restart the build of the runtime after removing the > various timestamps in $(builddir)/gcc and $(builddir)/$(target)/libada. Will try :) (while working on alias oracle I would like to be able to LTO test Ada since it has some specialities in this area) Honza
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-16 Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- > BTW are all those type mismatch waning actually correct? I was looking into > the Ada manual for C compatibility and i think we implement it correctly, so > there should be no mismatches if language standard is followed. It is easily > possible that I missed something important. Most warnings are in units implementing the low-level support of the language, in particular exceptions, so this is not pure Ada. A few others could be fixed. > BTW -fchecking=0 lets me to finish the build, but later I get wrong -fPIC > for ada runtime, which also seem new. You probably need to restart the build of the runtime after removing the various timestamps in $(builddir)/gcc and $(builddir)/$(target)/libada.
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 Jan Hubicka changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #3 from Jan Hubicka --- The failing check is Martin (Jambor's) sanity check of ipa-cp, so I am adding him to CC: at very first glance it looks like ipa bug exposed by LTO. BTW are all those type mismatch waning actually correct? I was looking into the Ada manual for C compatibility and i think we implement it correctly, so there should be no mismatches if language standard is followed. It is easily possible that I missed something important. BTW -fchecking=0 lets me to finish the build, but later I get wrong -fPIC for ada runtime, which also seem new.
[Bug ipa/90891] lto-bootstrap with ada enabled broken on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90891 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jan Hubicka --- Yep, i was looking for bootstrap while searching the PR. *** This bug has been marked as a duplicate of bug 90889 ***
[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- *** Bug 90891 has been marked as a duplicate of this bug. ***
[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 --- Comment #2 from Tom de Vries --- Romain, For commit "[libbacktrace] Add btest_lto", I added the noclone attribute next to each noinline attribute in btest.c. Perhaps this is needed as well in edtest.c and ttest.c. Can you try this and see if this fixes the problem you're seeing?
[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67696 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > Propose to mark this resolved-fixed. No objections, so marking this resolved-fixed.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #13 from Tom de Vries ---
(In reply to Tom de Vries from comment #11)
> (In reply to Thomas Schwinge from comment #1)
> > Same for OpenACC ('!$acc parallel copyout(v)').
> >
> >
> > Thsi sounds similar to PR85063,
> > > com> "[PATCH, PR85063] Fix switch conversion in offloading functions".
>
> There is a certain difference. There, switch conversion introduces a static
> var, while there is none in the source.
>
Oops, I just read in comment 0 "Fortran front-end is creating a local static
array", so you're right, this is similar.
[Bug d/90559] Out of memory because of negative length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90559 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2019-06-16 CC||ibuclaw at gcc dot gnu.org Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Well, actually, partially fixed. There's still some pretty bad handling of very large arrays within the dmd frontend itself. One of the problems being that it represents the initializer as one big contiguous array in memory in the frontend AST, and this initializer could be copied multiple times if used during CTFE. I think ultimately to cloes this, array initializers should be represented sparsely, but that would be a bigger internal change to dmd itself.
[Bug d/90863] ICE in StatementSemanticVisitor::visit, at d/dmd/statementsem.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90863 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272352.
[Bug d/90559] Out of memory because of negative length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90559 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fixed in r272351
[Bug d/90560] ICE in visit, at d/dmd/dcast.c:1872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90560 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fixed in r272348
[Bug d/90762] ICE in resolvePropertiesX, at d/dmd/expression.c:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90762 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272347.
[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fixed in r272340 and r272345
[Bug d/90761] ICE in visit, at d/dmd/dcast.c:883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90761 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272346
[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Fixed in r272344
[Bug d/90604] ICE in sizemask, at d/dmd/mtype.c:2542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90604 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272343
[Bug d/90602] ICE: null field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90602 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272342
[Bug d/90661] ICE in AlignDeclaration::syntaxCopy, at d/dmd/attrib.c:670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90661 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272341
[Bug d/90660] ICE in TypeQualified::resolveHelper, at d/dmd/mtype.c:6738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90660 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- Fixed in r272339
[Bug d/90863] ICE in StatementSemanticVisitor::visit, at d/dmd/statementsem.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90863 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:50:31 2019 New Revision: 272352 URL: https://gcc.gnu.org/viewcvs?rev=272352=gcc=rev Log: PR d/90863 d/dmd: Merge upstream dmd 6e44734cc Fixes segmentation fault in StatementSemanticVisitor::visit. Reviewed-on: https://github.com/dlang/dmd/pull/10033 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19955.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/blockexit.c trunk/gcc/d/dmd/statementsem.c
[Bug d/90559] Out of memory because of negative length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90559 --- Comment #2 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:50:20 2019 New Revision: 272351 URL: https://gcc.gnu.org/viewcvs?rev=272351=gcc=rev Log: PR d/90559 d/dmd: Merge upstream dmd 7afcc60c3 Partially fixes out of memory because of negative length. Reviewed-on: https://github.com/dlang/dmd/pull/10025 gcc/d/ChangeLog: 2019-06-16 Iain Buclaw PR d/90559 * d-target.cc (Target::_init): Reduce max static data size to INT_MAX. Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/d-target.cc trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/clone.c trunk/gcc/d/dmd/expressionsem.c trunk/gcc/d/dmd/mtype.c trunk/gcc/d/dmd/mtype.h trunk/gcc/testsuite/gdc.test/fail_compilation/staticarrayoverflow.d
[Bug d/90560] ICE in visit, at d/dmd/dcast.c:1872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90560 --- Comment #2 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:49:43 2019 New Revision: 272348 URL: https://gcc.gnu.org/viewcvs?rev=272348=gcc=rev Log: PR d/90560 d/dmd: Merge upstream dmd c6887d9bb Fixes segmentation fault in castTo::CastTo::visit. Reviewed-on: https://github.com/dlang/dmd/pull/10007 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19890a.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19890b.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/mtype.c
[Bug d/90762] ICE in resolvePropertiesX, at d/dmd/expression.c:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90762 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:49:30 2019 New Revision: 272347 URL: https://gcc.gnu.org/viewcvs?rev=272347=gcc=rev Log: PR d/90762 d/dmd: Merge upstream dmd b0cd59177 Fixes segmentation fault in resolvePropertiesX. Reviewed-on: https://github.com/dlang/dmd/pull/10006 Added: trunk/gcc/testsuite/gdc.test/compilable/traits.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/statementsem.c
[Bug tree-optimization/89376] ICE: Segmentation fault (in oacc_entry_exit_ok_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89376 Tom de Vries changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom de Vries --- Patch with test-case committed, marking resolved-fixed.
[Bug d/90604] ICE in sizemask, at d/dmd/mtype.c:2542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90604 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:48:42 2019 New Revision: 272343 URL: https://gcc.gnu.org/viewcvs?rev=272343=gcc=rev Log: PR d/90604 d/dmd: Merge upstream dmd f30c5dc79 Fixes internal compiler error in Type::sizemask. Reviewed-on: https://github.com/dlang/dmd/pull/9998 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19898a.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19898b.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/intrange.c
[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650 --- Comment #3 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:48:53 2019 New Revision: 272344 URL: https://gcc.gnu.org/viewcvs?rev=272344=gcc=rev Log: PR d/90650 d/dmd: Merge upstream dmd ab03e2918 Fixes internal compiler error in fold_convert_loc. Reviewed-on: https://github.com/dlang/dmd/pull/9996 gcc/testsuite/ChangeLog: 2019-06-16 Iain Buclaw PR d/90650 * gdc.dg/pr90650a.d: New test. * gdc.dg/pr90650b.d: New test. Added: trunk/gcc/testsuite/gdc.dg/pr90650a.d trunk/gcc/testsuite/gdc.dg/pr90650b.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/expressionsem.c trunk/gcc/d/dmd/mtype.c trunk/gcc/d/dmd/statementsem.c trunk/gcc/testsuite/ChangeLog
[Bug d/90761] ICE in visit, at d/dmd/dcast.c:883
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90761 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:49:18 2019 New Revision: 272346 URL: https://gcc.gnu.org/viewcvs?rev=272346=gcc=rev Log: PR d/90761 d/dmd: Merge upstream dmd d912f4e49 Fixes segmentation fault in implicitConvTo::ImplicitConvTo::visit. Reviewed-on: https://github.com/dlang/dmd/pull/10005 Added: trunk/gcc/testsuite/gdc.test/compilable/test19941.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19941.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/expressionsem.c
[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:49:06 2019 New Revision: 272345 URL: https://gcc.gnu.org/viewcvs?rev=272345=gcc=rev Log: PR d/90651 d/dmd: Merge upstream dmd 0f6cbbcad Fixes segmentation fault in FuncDeclaration::semantic3. Reviewed-on: https://github.com/dlang/dmd/pull/10003 gcc/d/ChangeLog: 2019-06-16 Iain Buclaw * typeinfo.cc (object_module): New variable. (make_frontend_typeinfo): Update signature. Set temporary on generated TypeInfo classes. (create_tinfo_types): Set object_module. Move generation of front-end typeinfo into ... (create_frontend_tinfo_types): ... New function. (layout_typeinfo): Call create_frontend_tinfo_types. (layout_classinfo): Likewise. (layout_cpp_typeinfo): Likewise. (create_typeinfo): Likewise. Added: trunk/gcc/testsuite/gdc.test/fail_compilation/extra-files/minimal/ trunk/gcc/testsuite/gdc.test/fail_compilation/extra-files/minimal/object.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19911a.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19911b.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19911c.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19922.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19923.d Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/expressionsem.c trunk/gcc/d/dmd/func.c trunk/gcc/d/dmd/mtype.c trunk/gcc/d/typeinfo.cc
[Bug d/90661] ICE in AlignDeclaration::syntaxCopy, at d/dmd/attrib.c:670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90661 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:47:57 2019 New Revision: 272341 URL: https://gcc.gnu.org/viewcvs?rev=272341=gcc=rev Log: PR d/90661 d/dmd: Merge upstream dmd c74e624c9 Fixes segmentation fault in AlignDeclaration::syntaxCopy. Reviewed-on: https://github.com/dlang/dmd/pull/10001 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19914.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19915.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/attrib.c trunk/gcc/testsuite/gdc.test/compilable/aggr_alignment.d
[Bug d/90602] ICE: null field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90602 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:48:23 2019 New Revision: 272342 URL: https://gcc.gnu.org/viewcvs?rev=272342=gcc=rev Log: PR d/90602 d/dmd: Merge upstream dmd 420cce2a6 Fixes internal compiler error during CTFE. Reviewed-on: https://github.com/dlang/dmd/pull/9997 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19897.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/dinterpret.c
[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651 --- Comment #3 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:47:46 2019 New Revision: 272340 URL: https://gcc.gnu.org/viewcvs?rev=272340=gcc=rev Log: PR d/90651 d/dmd: Merge upstream dmd 78dc31152 Fixes bug where the object module was not always implicitly imported. Reviewed-on: https://github.com/dlang/dmd/pull/ Added: trunk/gcc/testsuite/gdc.test/compilable/test19912.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19912a.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19912b.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19912c.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19912d.d trunk/gcc/testsuite/gdc.test/fail_compilation/fail19912e.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/dmodule.c
[Bug d/90660] ICE in TypeQualified::resolveHelper, at d/dmd/mtype.c:6738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90660 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Jun 16 07:47:34 2019 New Revision: 272339 URL: https://gcc.gnu.org/viewcvs?rev=272339=gcc=rev Log: PR d/90660 d/dmd: Merge upstream dmd bbc5ea66a Fixes segmentation fault in TypeQualified::resolveHelper. Reviewed-on: https://github.com/dlang/dmd/pull/1 Added: trunk/gcc/testsuite/gdc.test/fail_compilation/fail19913.d Modified: trunk/gcc/d/dmd/MERGE trunk/gcc/d/dmd/mtype.c
[Bug tree-optimization/89376] ICE: Segmentation fault (in oacc_entry_exit_ok_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89376 --- Comment #1 from Tom de Vries --- Author: vries Date: Sun Jun 16 07:47:15 2019 New Revision: 272338 URL: https://gcc.gnu.org/viewcvs?rev=272338=gcc=rev Log: [openacc, parloops] Fix SIGSEGV in oacc_entry_exit_ok_1 When compiling the test-case with r268755, we run into a SIGSEGV in oacc_entry_exit_ok_1 when trying to dereference a NULL red: ... struct reduction_info *red; red = reduction_phi (reduction_list, use_stmt); tree val = PHI_RESULT (red->keep_res); ... Fix this by handling ref == NULL. Bootstrapped and reg-tested on x86_64. Build and reg-tested on x86_64 with nvptx accelerator. 2019-06-16 Tom de Vries PR tree-optimization/89376 * tree-parloops.c (oacc_entry_exit_ok_1): Handle red == NULL. * testsuite/libgomp.oacc-c-c++-common/pr89376.c: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr89376.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-parloops.c trunk/libgomp/ChangeLog
