http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
Nick Maclaren changed:
What|Removed |Added
CC||nmm1 at cam dot ac.uk
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: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56697
--- Comment #1 from Nick Maclaren 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56697
--- Comment #4 from Nick Maclaren 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
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
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679
--- Comment #1 from Nick Maclaren 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57368
--- Comment #1 from Nick Maclaren ---
Disabling --enable-checking=all causes it to build.
erity: 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
int main () {
std::vector memory(123);
}
Change the 'int' to void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
--- Comment #2 from Nick Maclaren ---
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 --- Well
> volatile void * is a pointer to volatile void and the po
: 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 fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
--- Comment #17 from Nick Maclaren ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
--- Comment #25 from Nick Maclaren ---
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
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=30305&action=edit
Gzipped tar file of sources, command to run the test and output
There are some ancient proble
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57617
Nick Maclaren changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57403
--- Comment #5 from Nick Maclaren ---
Because of the last comment, I am not going to close this as resolved,
invalid, but please do so if appropriate.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
With 4.8.1:
template
class weeble {
static constexpr int Ranks[sizeof...(Dims)] = {Dims...};
const int rank = sizeof...(Dims);
};
weeble<3,5> x;
produces:
junk.cpp:4:22: error: expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58037
--- Comment #2 from Nick Maclaren ---
Thanks. That's simpler than my workaround.
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
confusi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #2 from Nick Maclaren ---
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
r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #5 from Nick Maclaren ---
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 (
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
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:
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
using namespace std;
template
void weeble(Pack ... rest, double x) {
int y[] = {rest...};
for (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #2 from Nick Maclaren ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Nick Maclaren changed:
What|Removed |Added
CC||nmm1 at cam dot ac.uk
--- Comment #20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #23 from Nick Maclaren ---
(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
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&#x
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #25 from Nick Maclaren ---
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 -
>
>(In reply to Nick Maclaren from comment #23)
>
>> If __S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #27 from Nick Maclaren ---
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 "
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #29 from Nick Maclaren ---
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
33 matches
Mail list logo
