Re: What's the status of of D on mingw?
Am 25.04.19 um 20:05 schrieb Rainer Emrich: Does anybody knows what's the plans for D on mingw. AFAIS the frontend builds and is enabled for mingw. But the D runtime is disabled for mingw and doesn't build. A quick dive into the source showed that there is code for mingw target. But it looks like the wrong configuration is selected. Any ideas? Hi Rainer, it is correct that there are a few leftovers of previous MinGW support in druntime. That code is quite old: Back then upstream did only support the custom Digitalmars 32bit C library on Windows and MinGW was the only compiler targeting the msvcrt runtime. Then at some point upstream added support for msvcrt (CRuntime_Microsoft versioned code) but also broke MinGW code. We therefore did not push the MinGW config code when merging into GCC, as we knew MinGW was broken anyway. I've did some work on fixing MinGW, but progress there has been delayed by proper emutls support (integration of GCC emutls with the D garbage collector). Without such GC support, most things would seem to work, but you get random crashes once the GC starts to collect live data. We actually never had proper emutls GC support in MinGW/GDC (I think someone had patches to implement native TLS in GCC and binutils though). As we pushed emutls GC support a few days ago, I now revived my work-in-progress MinGW changes here: https://github.com/D-Programming-GDC/gcc/pull/14 This likely won't make it into GCC 9.1 anymore though, so it's probably up for 9.2. Bet regards, Johannes
Re: What's the status of of D on mingw?
Am 29.04.2019 um 09:59 schrieb Johannes Pfau: > Am 25.04.19 um 20:05 schrieb Rainer Emrich: >> Does anybody knows what's the plans for D on mingw. >> >> AFAIS the frontend builds and is enabled for mingw. But the D runtime is >> disabled for mingw and doesn't build. >> >> A quick dive into the source showed that there is code for mingw target. >> But it looks like the wrong configuration is selected. >> >> Any ideas? > > it is correct that there are a few leftovers of previous MinGW support > in druntime. That code is quite old: Back then upstream did only support > the custom Digitalmars 32bit C library on Windows and MinGW was the only > compiler targeting the msvcrt runtime. Then at some point upstream added > support for msvcrt (CRuntime_Microsoft versioned code) but also broke > MinGW code. We therefore did not push the MinGW config code when merging > into GCC, as we knew MinGW was broken anyway. > > I've did some work on fixing MinGW, but progress there has been delayed > by proper emutls support (integration of GCC emutls with the D garbage > collector). Without such GC support, most things would seem to work, but > you get random crashes once the GC starts to collect live data. We > actually never had proper emutls GC support in MinGW/GDC (I think > someone had patches to implement native TLS in GCC and binutils though). > > As we pushed emutls GC support a few days ago, I now revived my > work-in-progress MinGW changes here: > https://github.com/D-Programming-GDC/gcc/pull/14 That's really nice. > > This likely won't make it into GCC 9.1 anymore though, so it's probably > up for 9.2. Yeah, I think it won't make it into 9.1, but I may test on the gcc-9 branch. That's fine for me. Thanks for your work Rainer signature.asc Description: OpenPGP digital signature
Delayed warning
Hi! Is there a way to mark a TREE statement (or a variable) so that a warning is issued at a later stage if the statement has not been removed in the meantime? I am thinking, for example, of Fortran's -Warray-temporaries, which issues a warning in the front end even though the whole temporary array may be optimized away later. We could, for example, mark a call to malloc in such a way. Regards Thomas
Re: C provenance semantics proposal
On Thu, 25 Apr 2019, Peter Sewell wrote: > (The standard does also have a defect in its definition of equality - on > the one hand, it says that &x+1==&y comparison must be true > if they are adjacent, but on the other (in DR260) that everything > might be provenance-aware. My preference would be to resolve > that by requiring source-language == to not be provenance aware, > but I think this is a more-or-less independent thing.) I've argued (in bug 61502 which you reported) that whether two objects follow each other in the address space need not be constant for the lifetime of those objects (that following in the address space, for separate objects, means nothing other than certain properties of comparisons, and, in particular, need not be constant as a property applied to constant addresses). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-9-20190428 is now available
It seems this is actually from trunk and crontab needs updating to create snapshots from the branch and trunk appropriately? -- Joseph S. Myers jos...@codesourcery.com
Re: Delayed warning
On 4/29/19 8:24 AM, Thomas Koenig wrote: > Hi! > > Is there a way to mark a TREE statement (or a variable) so that > a warning is issued at a later stage if the statement has not been > removed in the meantime? > > I am thinking, for example, of Fortran's -Warray-temporaries, which > issues a warning in the front end even though the whole temporary > array may be optimized away later. We could, for example, mark > a call to malloc in such a way. I'm not aware of one, but I recently suggested the concept of __builtin_warning which would allow us to effectively delay a warning. The goal was to have the warning explicitly in the IL so that if the path to the warning was later determined infeasible the warning would just get removed by the standard unreachable code elimination optimization. This would allow us to avoid false positives due to the IL not being well enough optimized at the point where we discover something is potentially amiss. Jeff
Re: Delayed warning
On Mon, Apr 29, 2019 at 08:39:57AM -0600, Jeff Law wrote: > On 4/29/19 8:24 AM, Thomas Koenig wrote: > > Hi! > > > > Is there a way to mark a TREE statement (or a variable) so that > > a warning is issued at a later stage if the statement has not been > > removed in the meantime? > > > > I am thinking, for example, of Fortran's -Warray-temporaries, which > > issues a warning in the front end even though the whole temporary > > array may be optimized away later. We could, for example, mark > > a call to malloc in such a way. > I'm not aware of one, but I recently suggested the concept of > __builtin_warning which would allow us to effectively delay a warning. > > The goal was to have the warning explicitly in the IL so that if the > path to the warning was later determined infeasible the warning would > just get removed by the standard unreachable code elimination optimization. > > This would allow us to avoid false positives due to the IL not being > well enough optimized at the point where we discover something is > potentially amiss. FYI, I also raised the idea of delayed warnings in the C FE some time ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193#c3 Marek
Re: syncing the GCC vax port
On 3/30/19 3:03 AM, co...@sdf.org wrote: > hi folks, > > i was interesting in tackling some problems gcc netbsd/vax has. > it has some ICEs which are in reload phase. searching around, the answer > to that is "switch to LRA first". Now, I don't quite know what that is > yet, but I know I need to try to do it. > > As an initial step, I need to sync the source code. > netbsd/vax has some outstanding work on GCC. > > I've done this, and I can run programs built by this compiler: > http://coypu.sdf.org/gcc-9-vax.diff > > (My tree has more detail on the changes done: > https://github.com/gcc-mirror/gcc/compare/master...coypoop:vax ) > > Matt Thomas (the GCC VAX maintainer) is the author of most of these > changes, I suspect he will not be very responsive by email. > Not being the author, I might not be able to answer all the questions, > but I can try my best. > > How do I get this across? comments? straight to gcc-patches? :-) > > I know Jeff Law did not like the change to builtins.md as being wrong. I > can omit them, I forgot about it until typing this email :) > > caveat: had an ICE during reload in the build process, I hid it > under the rug with -O0. I don't recall what I objected to :-) From looking at the changes I'd be concerned about the changes from memory_operand to volatile_mem_operand. Without knowing more about the problem you're trying to solve it's hard to ACK something like this. The new "condjump" expander seems a bit under-specified. Is there some reason why you needed that expander and couldn't just add a name to a existing define_insn? A nit. In that expander you have "gen_rtx_NE(VOIDmode ..." There should be a space between the NE and the open parenthesis. That kind of nit is repeated several times. The changes in constraints.md do not seem to change functionality at all, just reordering the oprerands. However our preferred style is what's in there right now. ival >= 0 is the right way 0 <= ival is the wrong way. I noticed the patch turns off flag_dwarf2_cfi_asm. Is there a reason for that? But yet you create DEF_CFA notes in the prologue. Is it the case that the CFI bits just aren't ready for consumption yet? If not, then it may be easier to just not include those changes right now. I can't really comment on the changes to how addreses are handled in print_operand_address. I'd just have to assume they're correct. I don't know if we generally allow debug_rtx calls like are added. Usually we gcc_assert or gcc_unreachable. mkrtx needs a function comment and looks like its got some formatting problems (spaces vs tabs issues and missing space between function name an the open paren for arguments). Similarly for vax_output_movmemsi and legitimate_pic_operand_p, vax_decomposed_dimode_operand_p, You've got undocumented #ifdefs in legitimate_pic_operand_p. You've got incorrect operand ordering in the adjacent_operands_p changes. The netbsd specific changes to the zero_extract patterns looks strange. Why why not just have the right operand. And why change it in the first place? Those peepholes look strange. Why is the first insn not just removed as dead? And if these changes were done by Matt Thomas, does he have a copyright assignment on file? If not, then we can't really use them. These are large enough that they'd require an assignment. jeff
