It is not reproduced on my environment.

[yamato@master]/tmp% cat foo.h
#define int0 int
template <int,
class _Comp0=less,
class _Comp1=less<pair<int, int> > >
class Test : public set {
typedef int xxx;
};
#define int1 int
[yamato@master]/tmp% ~/var/ctags-github/ctags --options=NONE --sort=no -o - /tmp/foo.h
ctags: Notice: No options will be read from files or environment
int0	/tmp/foo.h	/^#define int0 /;"	d
Test	/tmp/foo.h	/^class Test : public set {$/;"	c
xxx	/tmp/foo.h	/^typedef int xxx;$/;"	t	class:Test	typeref:typename:int
int1	/tmp/foo.h	/^#define int1 /;"	d
[yamato@master]/tmp% ~/var/ctags-github/ctags --version
Universal Ctags 0.0.0(54afb0f9), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: May  1 2018, 04:57:38
  URL: https://ctags.io/
  Optional compiled features: +wildcards, +regex, +iconv, +option-directory, +xpath, +json, +interactive, +sandbox, +yaml, +aspell

Not sure if this matters, but here is my ctags --version:
Universal Ctags 0.0.0(744610c), Copyright (C) 2015 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
Compiled: May 11 2018, 13:33:26
URL: https://ctags.io/
Optional compiled features: +wildcards, +regex, +iconv, +option-directory

Could you run Universal-crags with following command line?

$ ctags  --options=NONE --fields='*' -o tags bad.h

Here is what I got:
!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_OUTPUT_MODE u-ctags /u-ctags or e-ctags/
!_TAG_PROGRAM_AUTHOR Universal Ctags Team //
!_TAG_PROGRAM_NAME Universal Ctags /Derived from Exuberant Ctags/
!_TAG_PROGRAM_URL https://ctags.io/ /official site/
!_TAG_PROGRAM_VERSION 0.0.0 /744610c/
int0 bad.h /^#define int0 /;" kind:macro line:1 language:C++ roles:def end:1

I can confirm the issue. @masatake your input file doesn't have the same line 3, because GitHub ate the <int> on that line. If you add it back, you get @tuarba's behavior. I edited the first comment to properly use code segments not to hide what looks like HTML tags.

So this means that it's the line 3's <int> part that confuses the C++ parser for some reason.

@b4n, thank you. Reproduced here. I have to update issue our issue template to let a report use tipple quotes for preformatting.

@pragmaware, could you look at this issue?

I've tried to minimize the reproducer. However, I cannot make it enough small.

template <class _Comp0=less<float>,
          class _Comp1=less<pair<long, double> > >
class Test : set<int> {
  char c;
};

Template nastiness... hell of corner cases. This is one of the hard bits.
I've got a fix for this case but it breaks the parser-cxx.r/less-than-operator-between-anglebrackets.d unit test, which is harder to fix and has been handled with some "tricks".

Food for thoughts.

How to figure out that the second < in

template<char i, bool B = i < 10> void f1(void) { } ...

is actually an operator an not a template angle bracket?

template<char i, bool B = i < 10> void f1(void) { } ...

How does a real compiler handle this?
It looks ambiguous syntax for me.

It is one of the test cases we have. The compiler knows that i is a variable and not a (template) type, because it's declared just before... but in theory it could be defined anywhere else.

How does a real compiler handle this?

One trick I've seen to make such things simpler to parse is to preprocess the tokens and insert special disambiguation tokens, like say the tokens were:

...
TEMPLATE 
LEFT_ANGLE 
IDENTIFIER 
IDENTIFIER 
COMMA
IDENTIFIER
IDENTIFIER
EQUAL
IDENTIFIER
LEFT_ANGLE
INTEGER
RIGHT_ANGLE
...

You scan the tokens looking for template< and then count < and > openings and closings and inject some tokens like:

...
TEMPLATE_START*
IDENTIFIER
IDENTIFIER
COMMA
IDENTIFIER
IDENTIFIER
EQUAL
IDENTIFIER
LEFT_ANGLE
INTEGER
TEMPLATE_END*
...

* = synthetic token, replacing original token(s)

Of course it's a dirty hack, and doesn't help with truly ambiguous stuff like this:

a < b > c;

Where it's literally impossible to tell whether it's an expression statement comparing a less-than b greater-than c or a variable declaration c of type a templated on b, without first resolving all of the type names. The joys of a crappy grammar 😄

The input is recorded as a test case triggering the bug. See #1756.