[Bug c++/50976] New: [C++0x] literal operator with unsigned long long parameter not accepted

[Bug c++/50976] New: [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

             Bug #: 50976
           Summary: [C++0x] literal operator with unsigned long long
                    parameter not accepted
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com
                CC: 3dw4rd@verizon.net


gcc 4.7.0 20111029 (experimental) in C++0x mode rejects the following code:

//---
int operator "" _abc(unsigned long long int);
//---

with the message:

"error: 'int operator"" _abc(long long unsigned int)' has invalid argument
list"

but according to 13.5.8 p3 this should be a valid parameter-declaration-clause
and the code should be accepted.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 11:49:46 UTC ---
I can't reproduce this error.
I have test cases in the tree that look exactly like this.
Look at udlit-args.C.  Grep "long long" in
gcc/testsuite/g++.dg/cpp0x/udlit-*.C.
I've had dozens of literal operators like this for months.

Could it be that there is a 'template<char...>' just above the declaration? 
Literal operator templates must have void argument.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 12:03:51 UTC ---
Created attachment 25701
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25701
Test case

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 12:05:06 UTC ---
(In reply to comment #1)
> Could it be that there is a 'template<char...>' just above the declaration? 
> Literal operator templates must have void argument.

No, there is nothing like this nearby. I compiled the code as written with the
flags

-std=c++0x -Wall

(with or without -pedantic), see attached test case. To give you more
information, here the result of the complete "-v -save-temps -std=c++0x -Wall"
compile step:

Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=C:\Program Files\Develop\gcc\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.7-20111029-mingw/configure --host=x86_64-w64-mingw32
--build=x86_64-unknown-linux-gnu --target=x86_64-w6
4-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/gcc/4.7-20111029
--with-sysroot=/home/gfortran/gcc-home/bi
nary/mingw32/cross/x86_64/gcc/4.7-20111029 --with-gcc --with-gnu-ld
--with-gnu-as --with-gmp=/home/gfortran/gcc-home/binary/mingw3
2/native/x86_64/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr
--with-mpc=/home/gfortran/gcc-home/binar
y/mingw32/native/x86_64/mpc
--with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/ppl
--with-cloog=/home/gfortran/gcc-ho
me/binary/mingw32/native/x86_64/cloog --with-host-libstdcxx='-lstdc++ -lsupc++
-lm' --enable-targets=i686-w64-mingw32,x86_64-w64-m
ingw32 --enable-cloog-backend=ppl --enable-lto --enable-languages=c,c++,fortran
--enable-libgomp --enable-threads=win32 --enable-s
tatic --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-libquadmath --enable-libquadmath-support --disable-nls
--disable-tls --disable-win32-registry
Thread model: win32
gcc version 4.7.0 20111029 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-Wall' '-mtune=generic'
'-march=x86-64'
 c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1plus.exe -E
-quiet -v -iprefix c:\program files\devel
op\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/ -U_REENTRANT main.cpp
-mtune=generic -march=x86-64 -std=c++0x -Wall -fpch-preproce
ss -o main.ii
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0/x86_64-w64-mingw32"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/
4.7.0/backward"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/4.7-20111029/home/gfortran/gcc-home/binary
/mingw32/native/x86_64/gcc/4.7-20111029/lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed"
ignoring duplicate directory "c:/program
files/develop/gcc/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-m
ingw32/include"
ignoring nonexistent directory
"/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/4.7-20111029/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/x86_64-w64-mingw32
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include/c++/4.7.0/backward
 c:\program files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/include
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed
 c:\program
files\develop\gcc\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-Wall' '-mtune=generic'
'-march=x86-64'
 c:/program
files/develop/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1plus.exe
-fpreprocessed main.ii -quiet -dumpbase main
.cpp -mtune=generic -march=x86-64 -auxbase main -Wall -std=c++0x -version -o
main.s
GNU C++ (GCC) version 4.7.0 20111029 (experimental) (x86_64-w64-mingw32)
        compiled by GNU C version 4.7.0 20111029 (experimental), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20111029 (experimental) (x86_64-w64-mingw32)
        compiled by GNU C version 4.7.0 20111029 (experimental), GMP version
5.0.1, MPFR version 3.0.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 709d110f6440eac9dcd57bc1d2fbf1ee
main.cpp:1:44: error: 'int operator"" _abc(long long unsigned int)' has invalid
argument list

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 12:47:41 UTC ---
I wonder if the testsuite was run when the gcc was built.
It should have raised a boatload of flags there.

Your test case runs like a charm on x86_64-unknown-linux-gnu.
------------------------------------------------------------------------------
ed@bad-horse:~/udlit_debug$ ../bin/bin/g++ -v
Using built-in specs.
COLLECT_GCC=../bin/bin/g++
COLLECT_LTO_WRAPPER=/home/ed/bin/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --with-ppl=/usr/local
--with-cloog=/usr/local --enable-cloog-backend=isl --enable-lto
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++
Thread model: posix
gcc version 4.7.0 20111031 (experimental) (GCC) 
ed@bad-horse:~/udlit_debug$ ../bin/bin/g++ -std=c++0x -c main.cpp 
ed@bad-horse:~/udlit_debug$ 
------------------------------------------------------------------------------

I can't imagine how this could be target dependent though.
I wonder if build logs could be found.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-03 12:54:03 UTC ---
(In reply to comment #4)
> Your test case runs like a charm on x86_64-unknown-linux-gnu.

I can confirm that, using the 4.7-20111029 snapshot 

> I can't imagine how this could be target dependent though.

Yes, very strange.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 13:04:57 UTC ---
(In reply to comment #4)
> gcc version 4.7.0 20111031 (experimental) (GCC) 

This difference shouldn't be essential, should it?

> I wonder if the testsuite was run when the gcc was built.
> It should have raised a boatload of flags there.
[..]
> I can't imagine how this could be target dependent though.
> I wonder if build logs could be found.

I wouldn't know where to find them :-(, but I always get my gcc installation
from

http://www.equation.com/servlet/equation.cmd?fa=fortran

and I cannot remember of having found a problem with them.

Could we possibly keep the bug open until - lets say - Monday? Hopefully a new
build is available then which I could try. Any other suggestion?

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #7 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 13:06:12 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > gcc version 4.7.0 20111031 (experimental) (GCC) 
> 
> This difference shouldn't be essential, should it?

(Sorry, my reply conflicted with Jonathan, his answer makes this question mood)

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-03 13:23:24 UTC ---
(In reply to comment #6)
> http://www.equation.com/servlet/equation.cmd?fa=fortran

That page implies those binaries contain some source modifications, but it's
not clear what they are or if they're relevant to this case.  They're obliged
by the GPL to provide source, so you could try emailing their support address
to ask what changes they make.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 13:47:15 UTC ---
This may well happen if perhaps 'unsigned long long int' doesn't map to
long_long_unsigned_type_node for this target.

Daniel, just for fun, and as a possible work around for you, what happens if
you use 'unsigned long int' or 'unsigned int'?

Ed

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #10 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 13:58:53 UTC ---
(In reply to comment #8)
I just send a corresponding email to the support address of this page. In
addition I removed my previous gcc installation completely and installed it
freshly, but no difference.

(In reply to comment #9)
> This may well happen if perhaps 'unsigned long long int' doesn't map to
> long_long_unsigned_type_node for this target.
> 
> Daniel, just for fun, and as a possible work around for you, what happens if
> you use 'unsigned long int' or 'unsigned int'?

I had the same idea and tested all these combinations including all signed
int/long/long long variants. I also validated that std::uintmax_t equals
unsigned long long. No difference: All forms are rejected in the same way. I
also tested all supported literal operator signatures. All of them work as
expected, except this one :-(.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #11 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-03 19:44:02 UTC ---
(In reply to comment #4)
> I can't imagine how this could be target dependent though.

I have a bit more information now: If I'm using the 32-bit version from
http://www.equation.com/servlet/equation.cmd?fa=fortran on a 32-bit system, I
have not this problem. I wonder whether this could be a mingw problem - I
remember that this caused problems once in a while. Is there a mingw subgroup
which could be asked about that?

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #12 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03 21:05:37 UTC ---
It could well be a mingw-w64 problem (there are two separate projects mingw and
mingw-w64 - http://mingw-w64.sourceforge.net/ you want the latter).  I remember
sometimes having trouble compiling minw-w64 on a 32-bit system.  I've had bad
code issues not compile issues though.

You might check on that site if they have a bug tracker and/or a list that
could help.  I use mingw-w64 through cygwin and I know they are not that close
to the bleeding edge on gcc.  I think they're on gcc-4.5.1 or so.

Finally, http://www.equation.com/servlet/equation.cmd?fa=fortran could be using
mingw-w64 but building gcc on their own.  Check these guys too.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-09
                 CC|                            |jason at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> 2011-11-09 19:08:29 UTC ---
Reproduced with a cross-compiler to x86_64-w64-mingw32.  The problem is that on
that target, size_type_node and long_long_unsigned_type_node are the same type,
so check_literal_operator_args sees a size_type_node argument without a string
argument and returns false even though the next if would allow it.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #14 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-09 20:21:46 UTC ---
Created attachment 25774
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25774
Potential patch #1

I'll regtest this trivial patch when I get home.

I Just moved the checks for the strings and the length after the numeric value
checks.

Jason, could you check this on your cross compiler?

This seems simplest - it keeps the walk through the parameter list.  I could
put the check for size_type inside the POINTER_TYPE bit after a TREE_CHAIN
(argtype) and test.

Ed

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #15 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-09 20:23:19 UTC ---
Created attachment 25775
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25775
Potential patch #2

A different choice.  If I find a string, explicitly look for the size.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> 2011-11-09 21:53:19 UTC ---
I like the approach of #2, but it looks like that patch doesn't limit raw
operators to char*, but allows other character types as well.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #17 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-10 15:53:45 UTC ---
Created attachment 25785
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25785
Potentail patch #2a.

Here's a version of the second patch that actually compiles and doesn't cause
regressions.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[jason at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #18 from Jason Merrill <jason at redhat dot com> 2011-11-10 19:07:44 UTC ---
On 11/10/2011 10:53 AM, 3dw4rd at verizon dot net wrote:
> Potentail patch #2a.

> +		  t = TREE_VALUE (argtype);
> +		  if (!argtype)
> +		    return false;

If argtype is null, taking its TREE_VALUE will SEGV.

You can also check argtype == void_list_node to test for the end of the 
parameter list.

Jason

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #19 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-11 13:21:11 UTC ---
Created attachment 25796
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25796
Patch with corrections.

ChangeLog:

2011-11-11  Ed Smith-Rowland  <3dw4rd@verizon.net>

    PR c++/50976
    * typeck.c (check_literal_operator_args): Reorganize test for string
    operators so size_t search depends on finding string first.

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

--- Comment #20 from Jason Merrill <jason at gcc dot gnu.org> 2011-11-11 16:51:50 UTC ---
Author: jason
Date: Fri Nov 11 16:51:41 2011
New Revision: 181292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181292
Log:
    PR c++/50976
    * typeck.c (check_literal_operator_args): Reorganize test for string
    operators so size_t search depends on finding string first.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c

[Bug c++/50976] [C++0x] literal operator with unsigned long long parameter not accepted

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #21 from Jason Merrill <jason at gcc dot gnu.org> 2011-11-11 16:52:05 UTC ---
Fix applied, thanks.