What is the C++ compiler required to do with ill-formed programs according to the Standard?

Question

C++03 Standard defines well-formed program (1.3.14 [defns.well.formed]) as

a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2)

It further defines an ill-formed program (1.3.4 [defns.ill.formed]) as

input to a C++ implementation that is not a well-formed program (1.3.14)

and the Standard is full of statements such as "if X then the program is ill-formed" for example (2.13.1/3):

A program is ill-formed if one of its translation units contains an integer literal that cannot be represented by any of the allowed types.

Yet I haven't found what the C++ implementation is required to do with ill-formed programs.

Suppose I have an ill-formed program. Now what?

Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?

Answer 1

Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?

If the Standard does not specify otherwise, an implementation should emit a diagnostic message (error or warning). However, for some violations the Standard explicitly specifies that no diagnostic is required. In this case, the program is ill-formed, but implementations are not required to tell the user - usually, because doing so in the general case would be too difficult.

Concerning the One Definition Rule, for example, see Paragraph 3.2/4 of the C++11 Standard:

Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required.

Regarding the requirements on implementations when encountering a violation of a rule, Paragraph 1.4/2 specifies:

[...]

— If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute that program.

— If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.

— If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.

Also relevant is Paragraph 1.4/1, which explains what is meant by "diagnosable rules" in the Paragraph quoted above:

The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior.”

So to sum it up: if an ill-formed program contains a diagnosable violation for which the Standard does not explicitly specify "no diagnostic required", conforming implementations should emit a diagnostic.

Answer 2

Quoting [intro.compliance]§2:

• If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute that program.

• If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.

• If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.

I haven't found any other relevant passages in the standard. If we combine this with [defns.undefined]:

undefined behavior

behavior for which this International Standard imposes no requirements

[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. -end note ]

I'd say we arrive at "issue a diagnostic message and further the behaviour is undefined," because the standard doesn't say anything more about it.