[Bug fortran/54679] Erroneous "Expected P edit descriptor" in conjunction with L descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679 --- Comment #5 from Nick Maclaren --- That's the right message. Warning or error, it doesn't matter.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #25 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 10 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net - (In reply to Nick Maclaren from comment #23) If __STDC_IEC_559__ is unset or does not have the value 1, setting STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3, 7.6 and Annex F), unless the implementation explicitly chooses to extend the language to support it. You're wrong. The C standard doesn't say that. I am sorry, but it is you that is wrong. 6.10.8.3 says: __STDC_IEC_559__ The integer constant 1, intended to indica te conformance to the specifications in annex F (IEC 60559 floating-point arithmetic). and nothing about STDC FENV_ACCESS. 3.4.3 says: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 4. Conformance, paragraph 2, says: ... Undefined behavior is otherwise indicated in this International Standard by the words undefined behavior or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe behavior that is undefined. What explicit definition of behavior is there for the case when STDC FENV_ACCESS is set to on but __STDC_IEC_559__ is not set to one? As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. Regards, Nick Maclaren.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #27 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 What explicit definition of behavior is there for the case when STDC FENV_ACCESS is set to on but __STDC_IEC_559__ is not set to one? The behavior is defined. The standard says, e.g. for C99: 7.6.1 The FENV_ACCESS pragma The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes. I suggest looking up the word explicit in a dictionary. Unless __STDC_IEC_559__ is set to 1, what modes and flags exist (and, even more importantly) what there semantics are) is at best implicit and more realistically unspecified - see footnote 204 for a clear statement of that. Have you ever implemented a C system for an architecture with non-IEEE arithmetic but with modes and flags? Because I have, and I have used several others. As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. No. You are quite simply wrong. Regards, Nick Maclaren.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #29 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 The FENV_ACCESS pragma provides a means to inform the implementation whe n a program might access the floating-point environment to test floating-poi nt status flags or run under non-default floating-point control modes. I suggest looking up the word explicit in a dictionary. The above is an explicit definition. Where do you see an undefined behavior here? It is not an explicit definition of BEHAVIOR (my emphasis), and what it implies for any nnon-IEEE system is completely unclear. Of the two countries active during the standardisation of C99, one voted no on these grounds (among others). Note that the C standard doesn't explicitly say how a source file as a sequ ence of bytes is to be interpreted as a sequence of character, so that if you ju st restrict to the C standard, everything is undefined. Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, paragraph 1.1: Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary. ... You imply that you are also relying on some other standards or specifications. ISO/IEC Directives Part II is quite clear (in 6.2.2) that they shall be referenced in the ISO standard. Which ones are you referring to and why? If you are claiming that C99 and beyond support only systems that conform to IEEE 754, then I can tell you that was not the intention of WG21 at the time and is not a requirement of the standard. To repeat, how many other such systems are you familiar with? The grounds that the UK voted no to this aspect was that the whole 'IEEE 754' morass (including fenv.h) was neither dependent on __STD_IEC_559__ nor implementation-dependent nor sufficiently explicit to be interpreted on any non-IEEE system. The discussion is going nowhere. Now, at least that is true. Regards, Nick Maclaren.
[Bug libfortran/59108] New: ACTION='READ' is using O_CREAT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59108 Bug ID: 59108 Summary: ACTION='READ' is using O_CREAT Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk Running 'strace -v -e trace=open' on the following program: PROGRAM Main OPEN(11,FILE='wombat',ACTION='READ') OPEN(12,FILE='numbat',ACTION='READ',ACCESS='STREAM') OPEN(13,FILE='dingbat',ACTION='READ',ACCESS='DIRECT',RECL=8) END PROGRAM Main produces: open(wombat, O_RDONLY|O_CREAT, 0666) = 3 open(numbat, O_RDONLY|O_CREAT, 0666) = 4 open(dingbat, O_RDONLY|O_CREAT, 0666) = 5 Not merely does this create files when the user isn't expecting it, it fails if the directory or file system is protected against writing. wheeler$uname -a Linux wheeler 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux wheeler$gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap --enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float Thread model: posix gcc version 4.8.1 (GCC)
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Nick Maclaren nmm1 at cam dot ac.uk changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #20 from Nick Maclaren nmm1 at cam dot ac.uk --- Richard Biener's approach to the default is the one that matches the C standard and Vincent Lefèvre is mistaken. C11 7.6.1p2 says: ... If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined. The default state (‘‘on’’ or ‘‘off’’) for the pragma is implementation-defined. Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable. Because generated code and the library are potentially dependent on the rounding mode (including even floating point to integer conversion!), the default should remain that rounding mode support is off until each target has been thoroughly checked that it does NOT break. There are also very strong grounds for not wanting IEEE 754 support by default, anyway, because of the performance impact and because a lot of programs won't reset the state before calling external functions (and hence may well give wrong answers). That is especially true if the code is used within a C++ program or uses GPUs or some SIMD units - let alone OpenMP :-(
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #23 from Nick Maclaren nmm1 at cam dot ac.uk --- (In reply to Vincent Lefèvre from comment #21) Richard Biener's approach to the default is the one that matches the C standard and Vincent Lefèvre is mistaken. No, I'm correct. Defining it to be 'off' and not setting __STDC_IEC_559__ is very reasonable. No, this is really stupid. If the user *decides* to set the STDC FENV_ACCESS pragma to on, then the compiler must not assume that it is off (this bug is not about the default state). At least it must behave in this way if -std=c99 (or c11) has been used. Otherwise a compilation failure may be better than getting wrong results. If __STDC_IEC_559__ is unset or does not have the value 1, setting STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3, 7.6 and Annex F), unless the implementation explicitly chooses to extend the language to support it. So the user would get what he so richly deserves. (In reply to jos...@codesourcery.com from comment #22) So a key part of actually making rounding modes and exceptions work reliably would be working out a definition of GCC's default mode that allows more or less the same optimizations as at present, while allowing users wanting the full support (and consequent optimization cost) to specify the appropriate command-line options or FENV_ACCESS pragma to enable it. Yes. That won't deal with the correctness problems of introducing IEEE 754 support into code not set up to handle it, especially C++, of course. I tried to get WG21 to take a stand on that issue, but failed :-( Working out what on earth to do in such a case is likely to be a far fouler task than merely dealing with the performance problems :-(
[Bug c++/58527] New: Failures when a function parameter pack is not final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
Bug ID: 58527
Summary: Failures when a function parameter pack is not final
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
This may be already reported, but I can't see how to search for it. Sorry.
#include iostream
using namespace std;
templatetypename ... Pack
void weeble(Pack ... rest, double x) {
int y[] = {rest...};
for (int i = 0; i sizeof(y)/sizeof(*y); ++i) cout y[i] ;
cout x endl;
}
int main () {
weeble(123,456,789,3.1416);
}
fails with:
junk.cpp: In function 'int main()':
junk.cpp:12:30: error: no matching function for call to 'weeble(int, int, int,
double)'
weeble(123,456,789,3.1416);
^
junk.cpp:12:30: note: candidate is:
junk.cpp:5:6: note: templateclass ... Pack void weeble(Pack ..., double)
void weeble(Pack ... rest, double x) {
^
junk.cpp:5:6: note: template argument deduction/substitution failed:
junk.cpp:12:30: note: candidate expects 1 argument, 4 provided
weeble(123,456,789,3.1416);
^
Now, it may well be illegal, though I can't spot anything in C++11.
It would certainly be illegal if it were the cstdarg 'equivalent'.
But it is parsable, in theory, even more so in my original form.
However, that's not my sole point. If it is illegal, why isn't it
being rejected when the function template is being parsed, rather than
left to type resolution to fail weirdly? Intel is even more amusing,
incidentally :-)
Other information:
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-Wall' '-Wextra' '-Wno-unused-parameter'
'-fno-elide-constructors' '-g' '-O3' '-I' '/home/nmm/Courses/C++/Includes' '-I'
'.' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Linux wheeler 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200
x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/58527] Failures when a function parameter pack is not final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- Thanks. I can't use your fix, because I am trying to write a generic multi-dimensional array class for possible inclusion in the standard, and demanding such usages from end users is Not On. There are other possibilities, of course. I would be interested in a reference to the wording in the standard, if you know it offhand. I failed to find it. But that doesn't address the other point. Even if C++ allows a parameter pack in a position where it cannot be deduced (and that would not be at all surprising), good practice would be to give at least a warning. And I did specify -Wall -Wextra :-)
[Bug fortran/58200] New: Option fcheck is misleadingly located in option descriptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200 Bug ID: 58200 Summary: Option fcheck is misleadingly located in option descriptions Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk I am not sure whether this should be against fortran or web. Using: http://gcc.gnu.org/onlinedocs/gfortran/ With most portable compilers, code generation options are traditionally used for variations in the target interface, and not to introduce functionality. Worse, the top-level entry says: 2.9 Options for code generation conventions When looking for run-time checking/debugging options, the obvious place is: 2.5 Options for debugging your program or GNU Fortran followed by: 2.8 Influencing runtime behavior But fcheck is in the 2.9! The simplest solution would be an extra paragraph in 2.5 saying that, for run-time checking options, see 2.9.
[Bug c++/58093] New: Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
Bug ID: 58093
Summary: Semi-bogus warning about narrowing conversions and
variadic templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
This may be related to 45397 and 53661, but it's not clear. The diagnostic
is both confusing and makes many uses of variadic templates extremely
confusing to their users.
4.13 [conv.rank], 4.7 [conv.integral] and 5 [expr] make it pretty clear
that this is not a narrowing conversion, which makes the diagnostic very
confusing. I agree that it potentially changes value, but the wording
could be better (e.g. 'loss of sign'). That's the trivial part of this
report.
The more serious (but still minor) one is that I don't think that this
is a soluble problem for the variadic template writer. It is unreasonable
to have to convert arguments explicitly, when it's automatic under almost
all circumstances.
The following program:
#include iostream
using namespace std;
templatetypename ... Pack
void weeble (Pack ... Dims) {
size_t r[] = {Dims...};
for (int i = 0; i sizeof...(Dims); ++i)
std::cout r[i];
std::cout std::endl;
}
int main() {
weeble(7,13,42,69);
}
produces:
junk.cpp: In instantiation of 'void weeble(Pack ...) [with Pack = {int, int,
int, int}]':
junk.cpp:13:22: required from here
junk.cpp:6:26: warning: narrowing conversion of 'Dims#0' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
size_t r[] = {Dims...};
^
junk.cpp:6:26: warning: narrowing conversion of 'Dims#1' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#2' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#3' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
g++ -v produces:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- I have no idea why you think that it is a narrowing conversion. The references I gave have been essentially unchanged since C90, and there is required to be no loss of information. All values of int can be represented in unsigned long in any conforming implementation. The primary condition of 8.5.4 p7 is fulfilled, and therefore the exception is irrelevant. This was clarified in C99 6.2.6.2. No, I did not support that interpretation in C90, but it's the one WG14 adopted. But it's merely a confusing diagnostic, and is therefore lost in the multitude of such things. Thank you for your correction on the templates - I was still thinking in terms of arguments and not patterns!
[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093 --- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk --- I did. Please read what the C++ standard says about conversions. 4.7 [conv.integral] paragraph 2 is a paraphrase of wording that has been in every C and C++ compiler since C90, and states that all integers (negative and positive) can be represented in unsigned ones of an equal or greater rank. Indeed, this was and is a design requirement in the parts of the library that use -1 converted to an unsigned integer as a result type. I can't be bothered to pursue this one further - as I said, one more confusing diagnostic is neither here nor there.
[Bug c++/58037] New: sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
Bug ID: 58037
Summary: sizeof... accepted only in some contexts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
With 4.8.1:
templateint ... Dims
class weeble {
static constexpr int Ranks[sizeof...(Dims)] = {Dims...};
const int rank = sizeof...(Dims);
};
weeble3,5 x;
produces:
junk.cpp:4:22: error: expected ';' at end of member declaration
const int rank = sizeof...(Dims);
^
junk.cpp:4:28: error: expected unqualified-id before '...' token
const int rank = sizeof...(Dims);
^
junk.cpp:4:22: error: expected primary-expression at end of input
const int rank = sizeof...(Dims);
^
That doesn't look right, especially as that use of sizeof... is almost
straight out of the standard.
For what it is worth, -v produces:
Using built-in specs.
COLLECT_GCC=/home/nmm/GCC/bin/g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug c++/58037] sizeof... accepted only in some contexts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- Thanks. That's simpler than my workaround.
[Bug c++/57617] OpenMP critical does not seem to synchronise correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617 Nick Maclaren nmm1 at cam dot ac.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Nick Maclaren nmm1 at cam dot ac.uk --- Brilliant. I had finger trouble with SSH. I do not know how I managed to look at the wrong version of the code for so long, but the update-in-critical failures for both compilers are my error. I shall change it to resolved but, if it resurfaces, it's my error. Sorry.
[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403 --- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk --- Because of the last comment, I am not going to close this as resolved, invalid, but please do so if appropriate.
[Bug c++/57617] New: OpenMP critical does not seem to synchronise correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617 Bug ID: 57617 Summary: OpenMP critical does not seem to synchronise correctly Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk Created attachment 30305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30305action=edit Gzipped tar file of sources, command to run the test and output There are some ancient problems that match this (e.g. 45025), but I can't find a new one. I have written a portable, multi-interface memory consistency checker for some common 'atomic' paradigms, and one of my tests finds that gcc -fopenmp isn't behaving. In the attached files, look for 'NOT expected' in output - I will report the store/load one separately. Regrettably, there is no documentation yet and this is not stripped down, but the code is structured so that the relevant function's assembler can be inspected (with -O0 at least). I ran commands to generate output. If you find a bug in my code, I shan't be surprised :-(
[Bug c++/57618] New: OpenMP atomic read and write are not sequentially consistent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57618 Bug ID: 57618 Summary: OpenMP atomic read and write are not sequentially consistent Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk See bug 57617 for the data and more description. But the same program finds that OpenMP atomic read and write are not sequentially consistent. That will assuredly cause wrong answers when yer everage programmer attempts to use them. But should they be? If you can decode any specification on this matter from what OpenMP are pleased to call a standard, you are more intelligent than I am. So is this a bug, a gotcha or a feature?
[Bug libstdc++/57582] New: clone is effectively reserved by iostream and should not be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57582
Bug ID: 57582
Summary: clone is effectively reserved by iostream and should
not be
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
This is probably java leaking into C++, or something of that nature.
The word clone does not occur in the C++ standard.
Under OpenSUSE 11.1, gcc 4.8.0 fails on the following code:
/home/nmm/GCC/bin/g++ -std=c++11 -Wall -Wextra -c -O3 junk.cpp
#include iostream
using namespace std;
class run;
class clone;
class cell {
cell (clone * c, run * r) {}
};
junk.cpp:8:17: error: expected ')' before '*' token
cell (clone * c, run * r) {}
Changing clone to clown and removing iostream both cure it.
[Bug libstdc++/51749] Including algorithm pollutes global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 --- Comment #17 from Nick Maclaren nmm1 at cam dot ac.uk --- I will just add to comment 8 that dumping large chunks of the POSIX namespace in isn't legal, unless WG21 have completely lost their marbles :-) But, as people have said, this isn't fixable by hacking - not least because it would have to be done in translation phase 4, not 8, so namespaces would not be a permissable tool. We shall have to wait for a proper fix.
[Bug libstdc++/51749] Including algorithm pollutes global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 --- Comment #25 from Nick Maclaren nmm1 at cam dot ac.uk --- Strictly, don't you mean feature selection macros? It isn't worth being too perfectionist on this, as the standards (both de jure and de facto) are an ungodly mess, and it is getting steadily harder to write portable code in C/C++/POSIX/etc. However, I strongly agree that taking the hard line (especially with -std=formal standard) is the best way to go. On the other hand, it is quite likely that a stricter line may require new options or feature selection macros - because, for example, there are codes that need a specific version of the language but also the extensions of a specific version of POSIX. Ugh.
[Bug libstdc++/57403] New: A vector of volatile int doesn't work, but one of volatile void * does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
Bug ID: 57403
Summary: A vector of volatile int doesn't work, but one of
volatile void * does
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
In gcc 4.8.0, the following program fails horribly:
#include vector
int main () {
std::vectorvolatile int memory(123);
}
Change the 'int' to void *' and it works. It fails under OpenSUSE 11.4
and OpenSUSE 12.1, both on AMD 64-bit, and with gcc 4.6.2 as well. The
messages are:
Test.cpp: In constructor 'std::vector_Tp, _Alloc::vector(std::vector_Tp,
_Alloc::size_type, const value_type, const allocator_type) [with _Tp =
volatile int; _Alloc = std::allocatorvolatile int; std::vector_Tp,
_Alloc::size_type = long unsigned int; std::vector_Tp, _Alloc::value_type =
volatile int; std::vector_Tp, _Alloc::allocator_type =
std::allocatorvolatile int]':
Test.cpp:4:41: error: could not convert '0' from 'int' to 'const volatile
value_type {aka const volatile int}'
std::vectorvolatile int memory(123);
^
Test.cpp: In function 'int main()':
Test.cpp:4:41: error: invalid initialization of reference of type 'const
volatile value_type {aka const volatile int}' from expression of type 'int'
In file included from /home/nmm/GCC/include/c++/4.8.0/vector:65:0,
from Test.cpp:1:
/home/nmm/GCC/include/c++/4.8.0/bits/stl_vector.h:296:7: error: in passing
argument 2 of 'std::vector_Tp, _Alloc::vector(std::vector_Tp,
_Alloc::size_type, const value_type, const allocator_type) [with _Tp =
volatile int; _Alloc = std::allocatorvolatile int; std::vector_Tp,
_Alloc::size_type = long unsigned int; std::vector_Tp, _Alloc::value_type =
volatile int; std::vector_Tp, _Alloc::allocator_type =
std::allocatorvolatile int]'
vector(size_type __n, const value_type __value = value_type(),
^
In file included from
/home/nmm/GCC/include/c++/4.8.0/x86_64-unknown-linux-gnu/bits/c++allocator.h:33:0,
from /home/nmm/GCC/include/c++/4.8.0/bits/allocator.h:47,
from /home/nmm/GCC/include/c++/4.8.0/vector:62,
from Test.cpp:1:
/home/nmm/GCC/include/c++/4.8.0/ext/new_allocator.h: In instantiation of 'void
__gnu_cxx::new_allocator_Tp::deallocate(__gnu_cxx::new_allocator_Tp::pointer,
__gnu_cxx::new_allocator_Tp::size_type) [with _Tp = volatile int;
__gnu_cxx::new_allocator_Tp::pointer = volatile int*;
__gnu_cxx::new_allocator_Tp::size_type = long unsigned int]':
/home/nmm/GCC/include/c++/4.8.0/bits/stl_vector.h:175:4: required from 'void
std::_Vector_base_Tp, _Alloc::_M_deallocate(std::_Vector_base_Tp,
_Alloc::pointer, std::size_t) [with _Tp = volatile int; _Alloc =
std::allocatorvolatile int; std::_Vector_base_Tp, _Alloc::pointer =
volatile int*; std::size_t = long unsigned int]'
/home/nmm/GCC/include/c++/4.8.0/bits/stl_vector.h:162:33: required from
'std::_Vector_base_Tp, _Alloc::~_Vector_base() [with _Tp = volatile int;
_Alloc = std::allocatorvolatile int]'
/home/nmm/GCC/include/c++/4.8.0/bits/stl_vector.h:298:23: required from
'std::vector_Tp, _Alloc::vector(std::vector_Tp, _Alloc::size_type, const
value_type, const allocator_type) [with _Tp = volatile int; _Alloc =
std::allocatorvolatile int; std::vector_Tp, _Alloc::size_type = long
unsigned int; std::vector_Tp, _Alloc::value_type = volatile int;
std::vector_Tp, _Alloc::allocator_type = std::allocatorvolatile int]'
Test.cpp:4:41: required from here
/home/nmm/GCC/include/c++/4.8.0/ext/new_allocator.h:110:30: error: invalid
conversion from 'volatile void*' to 'void*' [-fpermissive]
{ ::operator delete(__p); }
^
In file included from /home/nmm/GCC/include/c++/4.8.0/ext/new_allocator.h:33:0,
from
/home/nmm/GCC/include/c++/4.8.0/x86_64-unknown-linux-gnu/bits/c++allocator.h:33,
from /home/nmm/GCC/include/c++/4.8.0/bits/allocator.h:47,
from /home/nmm/GCC/include/c++/4.8.0/vector:62,
from Test.cpp:1:
/home/nmm/GCC/include/c++/4.8.0/new:97:6: error: initializing argument 1 of
'void operator delete(void*)' [-fpermissive]
void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
^
[Bug libstdc++/57403] A vector of volatile int doesn't work, but one of volatile void * does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403 --- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk --- On May 24 2013, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Well volatile void * is a pointer to volatile void and the pointer itself does not have the volatile on it. Aargh! Even after all this time, I still fall into that one :-( Yes, you are quite right, and I was making a stupid error. I think the only real issue here is the error message. IIRC allocators do not (and cannot) support volatile qualified types. That may well be true, but I can't find any such restriction in the C++ standard. It would be a great help if the library specification weren't so ambiguous - in this case, it hinges around the meaning of the word 'type', and the unqualified word is used with at least three meanings in the standard.
[Bug c/57368] New: Trying to build CilkPlus fails with an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57368 Bug ID: 57368 Summary: Trying to build CilkPlus fails with an ICE Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nmm1 at cam dot ac.uk This is different from 56485. I have tried to report it to the CilkPlus team, but the mechanism appears to be broken. I haven't tried stripping the problem down, as that is a lot of effort and it is worth finding out how best to proceed first. It fails with at least 4.6.2 and 4.8.0 in the same place. This is a reasonably modern 16-core AMD running OpenSUSE 12.1. The download is: svn co svn://gcc.gnu.org/svn/gcc/branches/cilkplus The build script is: ../configure --prefix=/home/nmm/CilkPlus --disable-bootstrap \ --enable-languages=c,c++,fortran \ --enable-werror=yes --enable-checking=all --disable-decimal-float make I shall retry without --enable-checking=all, but I typically work with all checks on :-) If particular information would be useful, please tell me what. The diagnostics are: /bin/sh ./libtool --tag=CC --mode=compile /home/nmm/cilkplus-source/object/./gcc/xgcc -B/home/nmm/cilkplus-source/object/./gcc/ -B/home/nmm/CilkPlus/x86_64-unknown-linux-gnu/bin/ -B/home/nmm/CilkPlus/x86_64-unknown-linux-gnu/lib/ -isystem /home/nmm/CilkPlus/x86_64-unknown-linux-gnu/include -isystem /home/nmm/CilkPlus/x86_64-unknown-linux-gnu/sys-include -DPACKAGE_NAME=\Cilk\ Runtime\ -DPACKAGE_TARNAME=\cilk-runtime\ -DPACKAGE_VERSION=\2.0\ -DPACKAGE_STRING=\Cilk\ Runtime\ 2.0\ -DPACKAGE_BUGREPORT=\c...@intel.com\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../../libcilkrts -I../../../libcilkrts/include -DIN_CILK_RUNTIME=1 -fpic -O3 -fcilkplus -DBUILD_USER=\nmm\ -DBUILD_HOST=\`hostname`\ -I../../../libcilkrts/include -DIN_CILK_RUNTIME=1 -fpic -O3 -fcilkplus -DBUILD_USER=\nmm\ -DBUILD_HOST=\`hostname`\ -std=c99 -g -O2 -MT metacall_impl.lo -MD -MP -MF .deps/metacall_impl.Tpo -c -o metacall_impl.lo `test -f 'runtime/metacall_impl.c' || echo '../../../libcilkrts/'`runtime/metacall_impl.c libtool: compile: /home/nmm/cilkplus-source/object/./gcc/xgcc -B/home/nmm/cilkplus-source/object/./gcc/ -B/home/nmm/CilkPlus/x86_64-unknown-linux-gnu/bin/ -B/home/nmm/CilkPlus/x86_64-unknown-linux-gnu/lib/ -isystem /home/nmm/CilkPlus/x86_64-unknown-linux-gnu/include -isystem /home/nmm/CilkPlus/x86_64-unknown-linux-gnu/sys-include -DPACKAGE_NAME=\Cilk Runtime\ -DPACKAGE_TARNAME=\cilk-runtime\ -DPACKAGE_VERSION=\2.0\ -DPACKAGE_STRING=\Cilk Runtime 2.0\ -DPACKAGE_BUGREPORT=\c...@intel.com\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -I. -I../../../libcilkrts -I../../../libcilkrts/include -DIN_CILK_RUNTIME=1 -fpic -O3 -fcilkplus -DBUILD_USER=\nmm\ -DBUILD_HOST=\needham\ -I../../../libcilkrts/include -DIN_CILK_RUNTIME=1 -fpic -O3 -fcilkplus -DBUILD_USER=\nmm\ -DBUILD_HOST=\needham\ -std=c99 -g -O2 -MT metacall_impl.lo -MD -MP -MF .deps/metacall_impl.Tpo -c ../../../libcilkrts/runtime/metacall_impl.c -fPIC -DPIC -o .libs/metacall_impl.o ../../../libcilkrts/runtime/metacall_impl.c: In function '__cilkrts_metacall': ../../../libcilkrts/runtime/metacall_impl.c:45:23: internal compiler error: RTL check: expected code 'code_label', have 'note' in create_metadata_label, at cilk.c:800 __notify_intrinsic(cilkscreen_metacall, d); ^ 0x9ff487 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) ../../gcc/rtl.c:773 0xcc6bc7 create_metadata_label ../../gcc/cilk.c:800 0xcc9038 expand_builtin_cilk_metadata(char const*, tree_node*) ../../gcc/cilk.c:1099 0x6a8005 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/builtins.c:6909 0x7c3826 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/expr.c:10260 0x6cb77c expand_call_stmt ../../gcc/cfgexpand.c:2180 0x6cb77c expand_gimple_stmt_1 ../../gcc/cfgexpand.c:2218 0x6cb77c expand_gimple_stmt ../../gcc/cfgexpand.c:2370 0x6cce65 expand_gimple_basic_block ../../gcc/cfgexpand.c:4204 0x6d060b gimple_expand_cfg ../../gcc/cfgexpand.c:4723 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [metacall_impl.lo] Error 1 make[2]: Leaving directory `/home/nmm/cilkplus-source/object/x86_64-unknown-linux-gnu
[Bug c/57368] Trying to build CilkPlus fails with an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57368 --- Comment #1 from Nick Maclaren nmm1 at cam dot ac.uk --- Disabling --enable-checking=all causes it to build.
[Bug c++/56697] New: Erroneous rejection of use of private constructor in public method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56697
Bug #: 56697
Summary: Erroneous rejection of use of private constructor in
public method
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@cam.ac.uk
What I believe is an erroneous rejection of a program. Unfortunately, the
C++ standard is too contorted in this area for me to be absolutely sure,
Anyway, Intel is happy with it.
wheeler$cat junk.cpp
class weeble {
public:
weeble () {}
class wurble {
int n;
wurble (int k) : n(k) {}
public:
wurble () : n(0) {}
};
wurble fred (int k) {return wurble(k);}
};
int main () {
weeble a;
weeble::wurble b = a.fred(42);
}
wheeler$/home/nmm/GCC/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/nmm/GCC/bin/g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8-20130127/configure --prefix=/home/nmm/GCC
--disable-bootstrap --enable-checking=all --enable-languages=c,c++,fortran :
(reconfigured) ../gcc-4.8-20130127/configure --prefix=/home/nmm/GCC
--disable-bootstrap --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.8.0 20130127 (experimental) (GCC)
wheeler$/home/nmm/GCC/bin/g++ junk.cpp
junk.cpp: In member function 'weeble::wurble weeble::fred(int)':
junk.cpp:6:9: error: 'weeble::wurble::wurble(int)' is private
wurble (int k) : n(k) {}
^
junk.cpp:10:41: error: within this context
wurble fred (int k) {return wurble(k);}
^
[Bug c++/56697] Erroneous rejection of use of private constructor in public method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56697 --- Comment #1 from Nick Maclaren nmm1 at cam dot ac.uk 2013-03-23 12:49:31 UTC --- Sorry, I should be clearer. I reported this because of the compiler difference, and because I can read the relevant wording of the standard either way. But I should have said Possibly erroneous.
[Bug c++/56697] Erroneous rejection of use of private constructor in public method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56697 --- Comment #4 from Nick Maclaren nmm1 at cam dot ac.uk 2013-03-23 13:46:33 UTC --- On Mar 23 2013, paolo.carlini at oracle dot com wrote: Which Intel out of curiosity? The 13.1.0 I have here at hand rejects it exactly 12.1. It's not my system, so I can't say more. Regards, Nick Maclaren.
[Bug middle-end/48814] [4.5/4.6/4.7 Regression] Incorrect scalar increment result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814 Nick Maclaren nmm1 at cam dot ac.uk changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #15 from Nick Maclaren nmm1 at cam dot ac.uk 2013-03-15 23:20:56 UTC --- I must correct some of the statements here. This is not a bug, and the intent of WG14 during the standardisation of C90 was that this should be undefined behaviour. This point was raised explicitly - unfortunately, those of us who wanted this area to be better specified did not prevail:-( This is a CHANGE in the C language introduced by C 2011. gcc may wish to adopt that, but that is not the same as saying this is a bug. As it merely degrades optimisation and does not break any working programs, it is not a major matter. The only reason that I am posting this after the decision has been taken is that there are other changes introduced by C11 that may not be so benign. There are many less than in C99, but still quite a lot. This should not be used as precedent.
[Bug fortran/54679] New: Erroneous Expected P edit descriptor in conjunction with L descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679 Bug #: 54679 Summary: Erroneous Expected P edit descriptor in conjunction with L descriptor Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@cam.ac.uk I get a spurious Expected P edit descriptor in format string in conjunction with the L0 descriptor in a non-trivial format. Changing the L0 to I0 or F0.0 works. It MAY be environment dependent, as I have also failed to see it in another test program. The oprogram is not worth attaching. PROGRAM Main IMPLICIT NONE CHARACTER(LEN=*), PARAMETER :: format1 = (A,1X,I2,1X,A,1X,I2,1X,A,2(1X,I0,1X),A,2(1X,I0,1X)), format2 = (A,1X,I2,1X,A,1X,I2,1X,A,2(1X,I0,1X),A,2(1X,L0,1X)), format3 = (A,1X,I2,1X,A,1X,I2,1X,A,2(1X,I0,1X),A,2(1X,F0.0,1X)) PRINT format1 PRINT format2 PRINT format3 END PROGRAM Main gives: junk.f90:8.55: PRINT format2 1 Error: Expected P edit descriptor in format string at (1)
[Bug fortran/54679] Erroneous Expected P edit descriptor in conjunction with L descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679 --- Comment #1 from Nick Maclaren nmm1 at cam dot ac.uk 2012-09-23 12:19:00 UTC --- Please reduce the severity to trivial, and change it to Confusing diagnostic! It's my error, at root, but gfortran could do better. I had forgotten the relevant constraint (C1006 in Fortran 2003). However, the syntax rule R1005 on the same page specifies that a width is mandatory for the L descriptor, so the actual error is that a width of zero is erroneous.
[Bug libfortran/53962] New: Tab handling with formatted stream output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Bug #: 53962 Summary: Tab handling with formatted stream output Classification: Unclassified Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@cam.ac.uk Created attachment 27787 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27787 A program to show the effect, and the difference from sequential Tab handling (or at least the T descriptor) is not being handled correctly for formatted stream output.
