For actual analysis as opposed to cutesy blog post demos I'd actually use

    vi test.s

But if you insist on doing things the hard way on stdout, GCC has got you covered as well. Add -o - to the command line.

Then I get:

        .file   "test.c"
        .text
        .globl  fn
        .type   fn, @function
    fn:
    .LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
    .LFE0:
        .size   fn, .-fn
        .ident  "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4"
        .section        .note.GNU-stack,"",@progbits

No thanks.

<shrug> At this point we have reduced your blog post's message from "Look at this amazing new feature! It's so novel and unique! All other compiler developers are complete idiots!" to "Sometimes when I read assembly code I'm not interested in debug information.". I am happy to concede this point.

There is rather a lot of garbage in those .s files for things like debuginfo, stray comments the GCC developers accidentally put in their asm output, linker commands, etc.

On the other hand it properly shows relocations (like global variable references) which disassemblers tend to get wrong.