Rather than a detailed review, just one thing that caught my eye...

   foreach (@$files) {
      $table{$_} = substr $_, 0, -2;  
   }
[download]

In this loop, the
    $table{$_} = substr $_, 0, -2;
statement seems intended to snip the extension off the path/filename of a C source file and associate the file name so truncated with the original, full name. It assumes the extension is always two characters, e.g., '.c'. It's not a bad assumption in this case, but of course immediately fails in the face of extensions like '.cc', '.cpp', etc., leaving one with a perhaps very puzzling bug — but of course, this will never happen! Whenever I encounter an assumption like this, old scars begin to throb and I feel a strong urge to program defensively.

Assuming one does not want to use well-tested and platform independent CPAN modules for manipulating file names, one might write something like (untested)
    for my $file_name (@$files) {
        (my $base_name = $file_name) =~ s{ [.] [^.]* \z }{}xms;
        $table{$file_name} = $base_name;
        }
which snips off the last '.whatever' extension regardless of its length, and, even though more verbose, has, I feel, a certain 'self-documentation' quality.

Update:

    `gcc $_ -o substr $_, 0, -2` foreach (@$files);
I couldn't get it to work syntactically... clarity is sacrificed... Is something like this even possible?

I agree with your concerns about clarity, but in any event, one way might be something like this (of course, you would use qx{...} instead of print qq{...}):

>perl -wMstrict -le
"print qq{gcc $_->[0] -o $_->[1]}
   for
     map [ $_, s{ [.] [^.]* \z }{}xmsr ],
     qw(see cee. foo.c foo/bar.cc foo/bar/baz.cpp)
     ;
"
gcc see -o see
gcc cee. -o cee
gcc foo.c -o foo
gcc foo/bar.cc -o foo/bar
gcc foo/bar/baz.cpp -o foo/bar/baz
[download]

(Prior to 5.14 and the introduction of the  //r regex modifier, you can use
    map { (my $o = $_) =~ s{ [.] [^.]* \z }{}xms;  [ $_, $o ] }
instead.)

Further Update: Or even:

>perl -wMstrict -le
"print qq{gcc $_ -o @{[ s{ [.] [^.]* \z }{}xmsr ]}}
   for qw(see cee. foo.c foo/bar.cc foo/bar/baz.cpp);
"
gcc see -o see
gcc cee. -o cee
gcc foo.c -o foo
gcc foo/bar.cc -o foo/bar
gcc foo/bar/baz.cpp -o foo/bar/baz
[download]

Thank you. Your well thought out examples of  print qq{...} / qx{...} in conjunction with the above reference to Re^2: How can we interpolate an expression?? provide an excellent foothold for the understanding of a concept that had originally seemed far-fetched to me. I think my bias towards clarity will prevail in this particular situation and I might stick with assigning pairs to a hash for the associated files. Is this exceedingly Novice?

"Whenever I encounter an assumption like this, old scars begin to throb and I feel a strong urge to program defensively."

In hindsight, I can definitely understand the ramifications of this assumption and plan on expanding the original script to include acceptance of a larger/more realistic spectrum of file extensions, as well as generating a more concentrated focus on defensive coding in my practice and learning.

You sir, have hit the nail on the head in regards to the kind of input I was hoping to receive in posting this for review. This is a pristine example of the quality of this community and why I prefer it to the plethora of available forums. Your response has opened several paths of inquisition in my mind, that I intend to follow to fruition. Thanks again!

... my bias towards clarity ... Is this exceedingly Novice?

In a professional/production environment, clarity is a jewel above price. The person who maintains your code months or years hence (and it may even be you; remember: the sanity you save may be your own) will sing your praises to the heavens if you give him or her a clear piece of code to work with.

I think I went one-track minded while writing this and hadn't even thought about expanding this to a point where the subs would need to be reused. I can see why calling @ARGV from inside a subroutine is a horrible habit to develop. Thank you for helping me catch it early on in my learning journey.

my $blah = 'foo.Q';
print qq{gcc $blah -o @{[  substr $blah, 0, -2  ]} and many more };
__END__
gcc foo.Q -o foo and many more
[download]

See Re^2: How can we interpolate an expression??

See perlintro, perlrequick for the regex portion, and for the template, see (tye)Re: Stupid question (and one discussion of that template Re^2: RFC: Creating unicursal stars)

#!/usr/bin/perl --
#~ 2012-10-11-01:58:20PDT by Anonymous Monk
#~ perltidy -csc -otr -opr -ce -nibc -i=4     
use strict; use warnings;
use Data::Dump qw/ dd /;

Main( @ARGV );
exit( 0 );

sub getFiles {
    my @files;
    foreach (@_) {
        if( /\.[cC]$/ ){
            if( -e $_ ){
                push @files, $_;
            } else {
                printf "Unreadable file: %s : (%d) %s\n", $_, $!, $!;
            }
        } else {
            print "Invalid file: $_\n";
        }
    }
    
    return \@files;
}

sub compile {
    my $files = shift;
    for( @$files ){
## all of these do the same thing, see perlintro / perlrequick for exp
+lanation
#~       my( @cmd ) = ( 'gcc', $_, '-o', /^(.+?)\.[^\.]+$/  );
#~       my( @cmd ) = ( 'gcc', $_, '-o', $_ =~ /^(.+?)\.[^\.]+$/  );
       my( @cmd ) = ( 'gcc', $_, '-o' );
#~       push @cmd, $1 if /^(.+?)\.[^\.]+$/  ;
       push @cmd, $1 if  $_ =~ /^(.+?)\.[^\.]+$/  ;
       dd \@cmd;
       system @cmd;
    }
}


sub Main {
    return print Usage() if not @_;
    my $files = getFiles( @_ );
    dd $files;
    compile( $files );
} ## end sub Main


sub Usage {
    <<"__USAGE__";

$0    
$0    list of files to process


__USAGE__

} ## end sub Usage


__END__
[download]

If you're going to be using qx, you might want to quote/escape vars (like filenames) with String::ShellQuote

Why not use make(1)? Here's a trivial makefile (save as Makefile):

foo: foo.o
bar: bar.o
baz: baz.o
[download]

After that, say make foo bar baz to compile all three binaries, if they are out of date.

You can even programmatically generate those lines with gcc -MM *.c

(The makefile I gave is not really complete, but might be enough. For further information, I recommend the document titled PMake -- a tutorial)

Thanks! While I do understand that there is always going to be more than one or two ways of accomplishing a task in Perl, as well as in *nix systems in general, I was attempting to accomplish this particular task primarily as an exercise in my Perl scripting. Thank you for the reference though. Google'd + Bookmarked; I've never quite understood makefiles, and now you've inspired me to investigate.

Make felt pretty impenetrable to me, too, as every example makefile I saw was usually a minimum of 20-30 lines.

The tutorial I linked you to is quite heavy. I would read up to chapter 3.1 (skip 2.7) -- that covers the essentials.

Anyway, I must warn you that PMake ("BSD Make") is not GNU Make. The latter can be found on pretty much every Linux system, and the most noticeable difference between them is the variable names. I find PMake's variables to be named much nicer ($(.TARGET) vs $@ or $(.IMPSRC) vs $<)

Anyway, you can manage without touching those variables, and I recommended that tutorial because it does a good job in explaining the basics.