On Linux, find can be invoked without a path. But on OSX, specifying the path is required. Consider changing line 82 of configure.ac from:

m4_foreach_w([ac_file],m4_esyscmd([find -name addconfig.ac]),

to

m4_foreach_w([ac_file],m4_esyscmd([find ./ -name addconfig.ac]),

I am having some trouble building on Mac OS X.

1. It complains of yellow and yylval not being defined. For instance,

CXX tools/ir-generator/ir-generator.o
In file included from ../tools/ir-generator/ir-generator.ypp:120:
:857:1: error: use of undeclared identifier 'yylloc'
YY_RULE_SETUP
^
:760:2: note: expanded from macro 'YY_RULE_SETUP'
YY_USER_ACTION
^
../tools/ir-generator/ir-generator-lex.l:5:7: note: expanded from macro 'YY_USER_ACTION'
yylloc = Util::SourceInfo(tmp, Util::InputSources::instance->getCurrentPosition()); }

extern YYSTYPE yylval;
extern YYLTYPE yylloc;

Not sure if this was correct, but it moved on.

1. Then, I ran into this. It seems like a value is being substituted for a template parameter, where it is expecting a type.

In file included from ../ir/ir.h:42:
../ir/nodemap.h:22:10: error: declaration of anonymous class must be a definition
template<class KEY, class VALUE,
^
../ir/nodemap.h:22:32: error: a non-type template parameter cannot have type 'class VALUE'
template<class KEY, class VALUE,
^
../ir/nodemap.h:25:55: error: expected a type
class ALLOC = std::allocator<std::pair<const KEY * const, const VALUE *>>>
^
frontends/p4/p4-parse.cpp:161:13: note: expanded from macro 'KEY'

define KEY 290

        ^

There are more errors, possibly resulting from the same cause, attached in the file here.
err.txt

1. I seem to run into these where I use g++ or clang++ on Mac (specified using CXX="..." ./boostrap.sh).

Not sure if this is important, but I use ports, not brew for installing bison, flex, boost, and auto tools.

  CXX      lib/stringify.o
In file included from /usr/include/x86_64-linux-gnu/gmp.h:51:0,
                 from /usr/include/gmpxx.h:33,
                 from ../lib/stringify.h:7,
                 from ../lib/stringify.cpp:2:
/usr/include/c++/4.9/cstddef:51:11: error: ‘::max_align_t’ has not been declared
   using ::max_align_t;
           ^
make: *** [lib/stringify.o] Error 1

This is a known bug, there are workarounds.
See https://gcc.gnu.org/gcc-4.9/porting_to.html

This is why it is disabled in lib/exceptions.h

Trying to compile this bug.zip using the P4-16 compiler,

p4test current.p4

halts with an error:

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../frontends/p4/typeChecking/typeChecker.cpp:118
<P4Program>(2029): typechecker mutated node <P4Program>(1750)

It seems to be an issue with the cube expressions.

ps. sorry for the .zip file -- GitHub won't accept p4 uploads for some reason...

The preprocessor interferes with the parsing of string literals - the ones spanning multiple lines.

The architecture v1model.p4 does not currently seem to provide a primitive to broadcast packets.

The spec allows side-effects in select labels, but all our examples use constant labels.
Handling multiple side-effects in the right order will require some compiler support.

While playing with a small example, I made a small typo that triggered a compiler bug. Note that in the deparser, I wrote h instead of hdr.

#include <v1model.p4>

header d_t {
  bit<32> f;
}

struct h {
  d_t d;
}

struct m { }

parser MyParser(packet_in b,
                out h hdr,
                inout m meta,
                inout standard_metadata_t standard_metadata) {
  state start {
    b.extract(hdr.d);
    transition accept;
  }
}

control MyVerifyChecksum(in h hdr,
                       inout m meta) {
  apply {}

}
control MyIngress(inout h hdr,
                  inout m meta,
                  inout standard_metadata_t standard_metadata) {
  apply {}
}
control MyEgress(inout h hdr,
               inout m meta,
               inout standard_metadata_t standard_metadata) {
  apply {}
}

control MyComputeChecksum(inout h hdr,
                          inout m meta) {
  apply {}
}
control MyDeparser(packet_out b, in h hdr) {
  apply {
    b.emit(h.d);
  }
}

V1Switch(MyParser(),
         MyVerifyChecksum(),
         MyIngress(),
         MyEgress(), 
         MyComputeChecksum(),
         MyDeparser()) main;

Does the bmv2 backend require that all meta data be put into a flat struct? I'm running into the following exception (omitting some details):

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../backends/bmv2/jsonconverter.cpp:1938
expected a bit<> or int<> type for struct M {
  l2_metadata_t l2_metadata; }.l2_metadata

This seems like an artificial restriction since the compiler should always to be able to inline nested struts or headers. Storing headers in the metadata is a common design pattern in switch.p4.

I have a program that compiles fine with the p4c-bm2-ss backend, but crashes at run-time with the small_switch bmv2. I compile with

p4c-bm2-ss --p4-16 switch.p4 -o switch.json

and run with

simple_switch switch.json

Compilation succeeds without complaints, but when I invoke simple_switch it crashes with the following error:

Calling target program-options parser
terminate called after throwing an instance of 'std::runtime_error'
  what():  in Json::Value::operator[](char const*)const: requires objectValue
Aborted (core dumped)

Here is a minimized version of the program:

#include <core.p4>
#include <v1model.p4>

struct H { };
struct M { };

parser ParserI(packet_in pk, out H hdr, inout M meta, inout standard_metadata_t smeta) {
    state start { transition accept; }
}

action drop(out standard_metadata_t smeta) { smeta.drop = 1; } // this global action seems to cause the problem

control IngressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {

    table forward {
        key = { }
        actions = { drop(smeta); }
        const default_action = drop;
    }

    apply {
        forward.apply();
    }

};

control EgressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {
    apply { }
};

control DeparserI(packet_out pk, in H hdr) {
    apply { }
}

control VerifyChecksumI(in H hdr, inout M meta) {
    apply { }
}

control ComputeChecksumI(inout H hdr, inout M meta) {
    apply { }
}

V1Switch(ParserI(), VerifyChecksumI(), IngressI(), EgressI(),
         ComputeChecksumI(), DeparserI()) main;

The problem seems to be caused by the global drop action. It disappears when I define a (parameter-free) version of drop inside the IngressI scope instead.

This program compiles successfully using p4test

package Pck();
extern void f<x>();
Pck() main;

while this program fails,

package Pck();
header x {}
extern void f<x>();
Pck() main;

with an error:

syntax error, unexpected TYPE
extern void f<x
              ^
error: 1 errors encountered, aborting compilation

Typically type parameters are binders so one wouldn't expect a prior declaration to affect whether the declaration of f is syntactically valid or not.

Following up on a posting in p4-dev...

The current code accepts such tables and generates a JSON file. Here is an example program:

header_type ethernet_t {
    fields {
        dstAddr : 48;
        srcAddr : 48;
        ethertype : 16;
    }
}

header ethernet_t ethernet;

parser start {
    extract(ethernet);
    return ingress;
}

action set_egress_port(port) {
    modify_field(standard_metadata.egress_spec, port);
}

table t1 {
    reads {
         ethernet.dstAddr : lpm;
         ethernet.srcAddr : lpm;
    }
    actions {
         set_egress_port;
    }
}

control ingress {
    apply(t1);
}

control egress {
}

However, when this JSON file is used with simple_switch BMv2 executable, it rejects it with the following message:

Table t1 features 2 LPM match fields

The current "official" compiler (p4c-bm) rejects such tables. The spec is not very explicit about whether this construct is allowed. If it is, then there needs to be a clear standard on how to handle entry priorities in this case and this will result in different PD API implementation in the first place.

I get the following error

what():  COMPILER BUG: ../frontends/p4/typeChecking/typeChecker.h:99
l2.p4(161): Could not find type of meta.ingress_metadata.bypass_lookups & (bit<16>)128;
        if (((meta.ingress_metadata.bypass_lookups & 0x0080) == 0) &&
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Aborted (core dumped)

The field bypass_lookups is of type bit<16>. I'm happy to provide more details if needed.

Tried to compile p4c in docker's ubuntu-latest image with clang++3.8, but got the following error.

root@d8f907559953:~/p4c/build# make -j4
CXX tools/ir-generator/ir-generator.o
CXX lib/crash.o
CXX lib/gc.o
CXX lib/hex.o
CXX lib/indent.o
CXX lib/json.o
CXX lib/log.o
../tools/ir-generator/ir-generator.ypp:140:13: error: use of undeclared identifier 'PARSE_BRACKET'
{ BEGIN(PARSE_BRACKET); }
^
../tools/ir-generator/ir-generator.ypp:170:49: error: use of undeclared identifier 'PARSE_BRACKET'
{ (yyval.kind) = NodeKind::Interface; BEGIN(PARSE_BRACKET); }
^
../tools/ir-generator/ir-generator.ypp:171:48: error: use of undeclared identifier 'PARSE_BRACKET'
{ (yyval.kind) = NodeKind::Abstract; BEGIN(PARSE_BRACKET); }
^
../tools/ir-generator/ir-generator.ypp:172:48: error: use of undeclared identifier 'PARSE_BRACKET'
{ (yyval.kind) = NodeKind::Concrete; BEGIN(PARSE_BRACKET); }
^
../tools/ir-generator/ir-generator.ypp:194:13: error: use of undeclared identifier 'PARSE_BRACKET'
{ BEGIN(PARSE_BRACKET); }
^
../tools/ir-generator/ir-generator.ypp:209:13: error: use of undeclared identifier 'PARSE_CTOR_INIT'
{ BEGIN(PARSE_CTOR_INIT); }
^
../tools/ir-generator/ir-generator.ypp:212:19: error: use of undeclared identifier 'NORMAL'
BEGIN(NORMAL); }
^
../tools/ir-generator/ir-generator.ypp:366:13: error: use of undeclared identifier 'yyrestart'
yyrestart(fp);
^
../tools/ir-generator/ir-generator.ypp:367:19: error: use of undeclared identifier 'NORMAL'
BEGIN(NORMAL);
^
CXX lib/match.o
9 errors generated.
Makefile:1828: recipe for target 'tools/ir-generator/ir-generator.o' failed
make: *** [tools/ir-generator/ir-generator.o] Error 1
make: *** Waiting for unfinished jobs....

The following program, which is essentially a no-op:

#include <v1model.p4>

struct h {
  bit<8> n;
} 

struct m {
}

parser MyParser(packet_in b,
                out h parsedHdr,
                inout m meta,
                inout standard_metadata_t standard_metadata) {
  state start {
    transition accept;
  }
}

control MyVerifyChecksum(in h hdr,
                       inout m meta,
                       inout standard_metadata_t standard_metadata) {
  apply {}

}
control MyIngress(inout h hdr,
                  inout m meta,
                  inout standard_metadata_t standard_metadata) {
  apply {}
}
control MyEgress(inout h hdr,
               inout m meta,
               inout standard_metadata_t standard_metadata) {
  apply {}
}

control MyComputeChecksum(inout h hdr,
                          inout m meta,
                          inout standard_metadata_t standard_metadata) {
  apply {}
}
control MyDeparser(packet_out b, in h hdr) {
  apply {}
}

V1Switch(MyParser(),
         MyVerifyChecksum(),
         MyIngress(),
         MyEgress(), 
         MyComputeChecksum(),
         MyDeparser()) main;

crashes with a compiler bug error, and a core dump using p4c-bm2-ss

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../backends/bmv2/jsonconverter.cpp:1871
<Type_Bits>(2315)bit<8>: Unexpected header type

Aborted (core dumped)

It does not handle correctly exits invoked from actions.

The problem is that BMv2 does not yet support setting the default actions.

The following program

//architecture
parser Parser();
parser MyParser(Parser p);
package Package(MyParser p1, MyParser p2);

//program
parser Parser1(Parser p) {
  state start {
   p.apply();
   transition accept;
  }
}

parser Parser2(Parser p) {
  state start {
   p.apply();
   transition accept;
  }
}

Parser1() p1;
Parser2() p2;

Package(p1,p2) main;

crashes with a compiler bug:

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../midend/inlining.cpp:255
bug2.p4(6): <Parameter>(33) <Type_Name>(32):Parser p expected an instance declaration
parser Parser1(Parser p) {
               ^^^^^^^^

The spec defines a concatenation operator ++ on bit strings:

Concatenation of two bit-strings, resulting in a bit-string whose length is the sum of the lengths, designated by the infix operator ++. The left bit-string provides the most significant bits.

However, the compiler does not currently seem to support it:

includes/parser.p4(378): error: ++: Concatenation not defined on bit<13> and bit<4>
        transition select(hdr.ipv4.fragOffset ++ hdr.ipv4.ihl ++ hdr.ipv4.protocol) {
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

default should be usable within a tuple in a select expression label

The field name intrinsic_metadata seems to be reserved or have some special meaning inside the meta data struct. Specifically, the program

#include <core.p4>
#include <v1model.p4>
typedef standard_metadata_t std_m;

header some_t { }

struct H { };
struct M {
    some_t intrinsic_metadata;
}

parser ParserI(packet_in pk, out H hdr, inout M meta, inout std_m smeta) {
    state start { transition accept; }
}

control VerifyChecksumI(in H hdr, inout M meta) {
    apply { }
}

control IngressI(inout H hdr, inout M meta, inout std_m smeta) {
    apply { }
}

control EgressI(inout H hdr, inout M meta, inout std_m smeta) {
    apply { }
}

control ComputeChecksumI(inout H hdr, inout M meta) {
    apply { }
}
control DeparserI(packet_out b, in H hdr) {
    apply { }
}

V1Switch(ParserI(), VerifyChecksumI(), IngressI(), EgressI(), ComputeChecksumI(),
         DeparserI()) main;

raises the exception

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../backends/bmv2/jsonconverter.cpp:1843
Expected a struct type

but if I rename the field intrinsic_metadata, the code compiles fine. Is this the intended behavior?

@ChrisDodd
The pass LowerExpressions from the p4c-bm2-ss compiler incorrectly transforms:
(packet.lookahead<bit<24>>())[0:0]
to
(bit<1>)((packet.lookahead<bit<24>>()) >> 0)
Repro in p4_14_samples/parser_dc_full.p4

Hi,

The flowlet switching example returns the following error on compiling to the bm2 target:

[flow:p4c]$  ./build/p4c-bm2-ss ./testdata/p4_16_samples/flowlet_switching.p4 
libc++abi.dylib: terminating with uncaught exception of type Util::CompilerBug: COMPILER BUG: ../backends/bmv2/jsonconverter.cpp:1659
/Users/ngsrinivas/p4c/p4include/v1model.p4(89): <Type_Enum>(123446): type not yet handled on this target
extern void digest<T>(in bit<32> receiver, in T data);
                                                      ^

Abort trap: 6

P4 grammar today cannot parse initializations of the form:

bit<8+8> p;
or
bit<16*8> p;
These would be useful for declaring identifiers that are multiples of bytes or half-words (for instance).

The program below compiles fine with the p4c-bm2-ss backend, put crashes with

Invalid number of parameters for primitive action clone_ingress_pkt_to_egress: expected 2 but got 1

when executed with the simple_switch bmv2:

#include <core.p4>
#include <v1model.p4>

struct H { };
struct M { };

parser ParserI(packet_in pk, out H hdr, inout M meta, inout standard_metadata_t smeta) {
    state start { transition accept; }
}

control IngressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {

    apply {
        clone(CloneType.I2E, smeta.clone_spec); // this causes the error
    }

}

control EgressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {
    apply { }
}

control DeparserI(packet_out pk, in H hdr) {
    apply { }
}

control VerifyChecksumI(in H hdr, inout M meta) {
    apply { }
}

control ComputeChecksumI(inout H hdr, inout M meta) {
    apply { }
}


V1Switch(ParserI(), VerifyChecksumI(), IngressI(), EgressI(),
         ComputeChecksumI(), DeparserI()) main;

I think this came up previously but would like to revisit.

In some architectures there are tables that can not be written to at run-time but can be programmed via firmware/ucode/etc at init time. Expressing this in P4 is not possible at the moment because the language expects all tables to be programmable at runtime.

To resolve this I have added an extension to an internal prototype compiler that accepts an initialization sequence similar to C style code. For example the following,

table fixed_map() {
key = {packet.parser_output : exact; }
actions = {
act0;
}
default_action = act1(0xdeadbeef);
size = 1024;
} = { 1 : act0(1), 2 : act0(2), 3 : act0(3), 4 : act(4)};

Where the initialization is after the '='. Any thoughts/opinions about adding this to the language proper? The change had fairly minimal impact to both p4 programs and prototype compiler code.

Some example use cases for these fixed tables is to load balance across multiple packet pipelines in a device, provide a way for specified packets to skip certain pipeline components (encryption, etc). In many cases it is fairly difficult (impossible?) for the compiler to infer the fixed table contents from the p4 program itself.

Thanks.

The compiler seems to allow explicit type application (AKA instantiation) for packages, but not for parser and control elements. This seems like a bug since the P4-16 grammar in the draft spec allows type application in all of these declarations.

Most programmer will want to let the inference engine calculate types, but it might be useful, for example, if they want to specify or document that a type variable was instantiated a particular way.

instantiation.zip

• instantiation-1.p4: compiles successfully
• instantiation-2.p4: produces an error
• instantiation-3.p4: produces an error
• instantiation-4.p4: produces an error

The spec mandates that errors are now in a separate namespace.
So one should write
error.NoError
instead of
NoError

with clang++-3.6:
for example:

  CXX      tools/ir-generator/ir-generator.o
In file included from ../tools/ir-generator/ir-generator.ypp:18:
In file included from ../tools/ir-generator/irclass.h:14:
../tools/ir-generator/type.h:24:21: warning: 'toString' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
    virtual cstring toString() const = 0;
                    ^
../lib/source_file.h:198:21: note: overridden virtual function is here
    virtual cstring toString() const = 0;

P4_16 allows one to declare parameters write-only using the keyword out. However, the type checker does not seem to actually enforce this. The following program compiles just fine:

#include <core.p4>
#include <v1model.p4>

struct H { };
header h {
  bit<1> f;
}
struct M { 
  h h;
};

parser ParserI(packet_in pk, out H hdr, inout M meta, inout standard_metadata_t smeta) {
    state start { transition accept; }
}

// meta is write-only
control Unsound(out M meta) {
  table t {
    key = {
      // here we read meta, even though we aren't technically allowed to
      meta.h.f : exact;
    }
    actions = { NoAction; }
  }

  apply {
    t.apply();
  }
}

control IngressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {

    Unsound() doUnsound;

    apply {
      doUnsound.apply(meta);
    }

}

control EgressI(inout H hdr, inout M meta, inout standard_metadata_t smeta) {
    apply { }
}

control DeparserI(packet_out pk, in H hdr) {
    apply { }
}

control VerifyChecksumI(in H hdr, inout M meta) {
    apply { }
}

control ComputeChecksumI(inout H hdr, inout M meta) {
    apply { }
}


V1Switch(ParserI(), VerifyChecksumI(), IngressI(), EgressI(),
         ComputeChecksumI(), DeparserI()) main;

The bmv2 backend testing script does not really check the results of negative tests for bmv2.

I get the error

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../frontends/p4/def_use.h:292
../frontends/p4/def_use.h:292: Null 

when trying to compile the following (minimized) program:

#include <core.p4>
#include <v1model.p4>
typedef standard_metadata_t std_meta_t;
struct H { };
struct M { };

parser ParserI(packet_in b, out H h, inout M m, inout std_meta_t s) {
    state start { transition accept; }
}

control IngressI(inout H hdr, inout M meta, inout std_meta_t std_meta) {
    apply { }
}

control EgressI(inout H hdr, inout M meta, inout std_meta_t std_meta) {

    action a() { }

    table t {
        key = { }
        actions = { a; }
    }

    IngressI() do;
    
    apply {
        switch(t.apply().action_run) {
            a: { 
                return; 
            }
            default: {
                do.apply(hdr, meta, std_meta);
            }
        }
    }
}

control VerifyChecksumI(in H hdr, inout M meta) {
    apply { }
}
control ComputeChecksumI(inout H hdr, inout M meta) {
    apply { }
}
control DeparserI(packet_out b, in H hdr) {
    apply { }
}

V1Switch(ParserI(), VerifyChecksumI(), IngressI(), EgressI(), ComputeChecksumI(),
         DeparserI()) main;

I get the following error message:

$ cd p4src && p4c-bm2-ss --p4-16 switch.p4 -o switch.json -D L2_PROFILE=1
terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../frontends/p4/typeMap.cpp:82
Could not find type for <Concat>(260488)

I suspect this may be related to #110 and may be caused by bit string concatenation.

The testdata/v1_2_samples/cast-call.p4 program is a repro of this bug.

The iterator of the IndexedVector can be used for reading; however, overwriting an element through the iterator will result in an inconsistent IndexedVector (the replace method can be used to achieve the desired effect).

A NameMap can only be used inline in the IR, since the IR generator does not support pointers to NameMaps.

Instantiating a control back and applying it within another causes the following bug in the inliner:

terminate called after throwing an instance of 'Util::CompilerBug'
  what():  COMPILER BUG: ../midend/inlining.h:138
control-inline.p4(19): Could not locate instance @name("vc") VC vc_0() invoked by vc.apply(tmp, tmp_0);
        VC() vc;
             ^^
control-inline.p4(20)
        vc.apply(hdr, meta);
        ^^^^^^^^^^^^^^^^^^^

Aborted (core dumped)

Here is a minimal example triggering the bug (see also pull request #116):

#include<core.p4>
#include<v1model.p4>

typedef standard_metadata_t std_m;
struct H { };
struct M { };

parser ParserI(packet_in pk, out H hdr, inout M meta, inout std_m smeta) {
    state start { transition accept; }
}

control VC(in H hdr, inout M meta) {
    apply { }
}

control Main(inout H hdr, inout M meta, inout std_m smeta) {
    apply { 
        // these two lines trigger a bug in the inliner, see 
        VC() vc;
        vc.apply(hdr, meta);
    }
}

control CC(inout H hdr, inout M meta) {
    apply { }
}

control DeparserI(packet_out b, in H hdr) {
    apply { }
}

V1Switch(ParserI(), VC(), Main(), Main(), CC(), DeparserI()) main;

Instead the build should just skip the BMv2 tests if the simulator is not installed.

The file lib/stringref.h makes a call to memrchr, which is on available on OSX. One possible fix would be to add the following:

ifdef MACH

void *
memrchr(const char _s, int c, size_t n)
{
const char * start = s;
const char * end = s + n - 1;
while(end>=start)
{
if(_end==c)
return (void *)end;
else
end--;
}
return NULL;
}

endif

Hi,

In the attached source file, when I call the action set_nhop from an apply block without arguments, I get a segfault from the compiler. The compiler should instead complain about missing action parameters.

[flow:p4c]$  ./build/p4test problematic.p4 
libc++abi.dylib: terminating with uncaught exception of type Util::CompilerBug: COMPILER BUG: ../lib/crash.cpp:226
Exiting with SIGSEGV

When I change the apply block in the ingress control to include a parameter for set_nhop, i.e.,

    apply {
        r1_filter();
        set_nhop(8w3);
    }
}

the file validates correctly.

problematic.txt

After renaming symbols the errors do not display the original symbol names.

If a visitor of the children of a NameMap returns an object with a different name, the object is inserted at the end of the NameMap instead of replacing the original object.