[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #14 from Dave Johansen --- Are the patches for 4.8 available or can they be made available? I would like to make a Software Collection (SCL) of version of 4.8 with these patches so it could be used on RHEL 6/7 without having to jump to a newer version of the compiler.
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #17 from Dave Johansen --- (In reply to kargl from comment #16) > See the fortran@ mailinglist archive. Fritz posted a patch against > 4.8 branch. Are the patches that were posted against 6.0? > That patch will never be committed to the 4.8 branch because that > branch is closed. I understand that 4.8 is EOL and I'm not requesting that they be applied. I'm just requesting that they be made available so that I can add them to an SCL build that I do myself using COPR ( https://fedorahosted.org/copr/ ) so they can be used on RHEL 6/7 (which have not been EOLed).
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #19 from Dave Johansen --- (In reply to kargl from comment #18) > (In reply to Dave Johansen from comment #17) > > (In reply to kargl from comment #16) > > > See the fortran@ mailinglist archive. Fritz posted a patch against > > > 4.8 branch. > > > > Are the patches that were posted against 6.0? > > > > What part of "Fritz posted a patch against 4.8 branch" > is not clear? > > What part of "See the fortran@ mailinglist archive" > is not clear. > > To be brutally clear: > https://gcc.gnu.org/ml/fortran/2016-03/msg00013.html Sorry, that was a complete oversight on my part. The recent patches were inline text and so I didn't notice the link to the gzipped attachment at the bottom of that email.
[Bug other/79046] New: g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 Bug ID: 79046 Summary: g++ -print-file-name=plugin uses full version number in path Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: davejohansen at gmail dot com Target Milestone: --- Created attachment 40493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40493&action=edit gcc patch for version from OpenSUSE g++ -print-file-name=plugin uses the full version number in the path when just the major version number is all that's required for compatibility. This means that plugins have to require the specific version of gcc and have to be rebuild after every update to gcc. For what it's worth, gcc on Ubuntu and OpenSUSE have already made this change and I've attached the patch from OpenSUSE that I believe does the change.
[Bug other/79046] g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 --- Comment #3 from Dave Johansen --- What are the chances that either of those changes will make it into the 7 release?
[Bug other/79046] g++ -print-file-name=plugin uses full version number in path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 --- Comment #6 from Dave Johansen --- Could that be made a guarantee? Right now, having to build plugins against the full version of GCC is a major pain for distributions and saying that GCC plugins are API/ABI stable for a major version would eliminate that pain point.
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #11 from Dave Johansen --- Can this please be reopened? It was determined in the glibc bugzilla that this is a gcc problem because of the incorrect setting of unique flag.
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #14 from Dave Johansen --- Could you please point me to how I can reproduce the issue with "RTLD_LOCAL with multiple loaded objects depending on the same library"? I would like to see if I can reproduce that issue with clang++ and icpc. Thanks, Dave
[Bug c++/68842] New: Better error output when template needed before dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68842 Bug ID: 68842 Summary: Better error output when template needed before dependent name Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: davejohansen at gmail dot com Target Milestone: --- Created attachment 36985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36985&action=edit Example code to demonstrate error Currently, when a dependent name cannot be correctly resolved and the template keyword is required, the error output is: test_template.cc: In instantiation of ‘void do_test() [with int N = 2]’: test_template.cc:20:14: required from here test_template.cc:15:15: error: invalid operands of types ‘’ and ‘int’ to binary ‘operator<’ t.do_nothing(0); The output is a correct representation of how the compiler is interpreting the code, but it is not helpful to a developer that doesn't understand the intricacies of templates and dependent name resolution. It would be nice if a more meaningful error output was given with at least a hint about the possible need for the template keyword.
