what is the actual size of the ROM in Tiva C Series

There is a table in the datasheet of the device you are interested which describes the memory map.  Table 2-4 of the datasheet for the TM4C123GH6Z indicates the memory space allocated for the internal ROM is from address 0x01000000 to 0x1FFFFFFF.  This doesn't mean that there is that much ROM on the device however.

I'm not sure why it really matters how much ROM is on the device.  This is not something that can be reprogrammed by the user.

I think that the real size of the ROM will be bigger than the flash of some MCUs.

I‘m confused that if it doesn't make that costs more.

Product pricing is often not bound nor restricted by strict, logical, linear specifications.  "What the market will bear" will most always be in play. 

Competitive postures - vendor short & long term sales/positioning goals - product acceptance and product manufacturability all play key roles.

Can report that tech investors most always prefer parts which are available (w/overall similarity in spec/performance/price) from multiple vendors - are readily available - and have a proven record of reliability. 

ROM circuits are significantly cheaper than Flash circuits.

I suspect that the total cost of the chip will be lower if more common functions are placed in ROM, even if they are not all used by all customers, compared to larger Flash to hold common and custom functions together.

Back in "the day" Masked ROM resulted in the lowest cost, programmed MCU. And God help you if that mask contained a "flaw."

Today - simply observe the (many & on-going) changes, fixes & errata which plague (most) vendor's MCUs & APIs. Code placed w/in ROM is then unable to benefit - at all - from such "changes/fixes/errata" which are well accommodated by Flash...

If what you list is true - would not a variety of vendors have introduced "ROM Only" MCUs - to reduce selling price? I have no awareness of such (modern) devices...

A "ROM Only" MCU would not allow for any custom code! That's why you don't see more of them.
The advantage of Flash plus ROM is that common subroutines, particularly for vendor peripherals, can be placed in ROM after being tested thoroughly. Then, only the custom code is placed in Flash, where it can conveniently be fixed.

Note that a very useful feature of CCS and Tiva is that the headers can deprecate any ROM function that actually has a bug, while still retaining the space-saving benefits of the remaining ROM functions that have no bugs.

p.s. The old-school MCUs cam in two flavors: EEPROM for development and Mask ROM for production. Only those who could afford the cost of a Mask ROM could take advantage of this. Another disadvantage was that there were two different chips being made. The modern solution ships a ROM that is useful to almost every product, at least in part, and the same chip has Flash. So, prototypes and production hardware have the same chip. The only disadvantage now is that if you're making millions of products and can afford a Mask ROM, perhaps you have to accommodate the slightly shorter live span of Flash compared to Mask ROM - but I don't think many manufacturers are in this situation, given the face pace of change these days.

Known - and agreed - but for, "ROM Only MCU would not allow for any custom code."
Our past - masked ROM MCUs - consisted entirely of our firm's "custom code!"

Hello X-Z.

Firstly you may want to take a look at the code that Chester made public for reading memory address spaces. Any address space. This was an issue raised by him here in the forum just one day ago at the following link: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/587445/2157765#2157765  

Regarding why one would need to know where ROM Start / End I can only say that this knowledge, among other things, gives you the opportunity with simple hacks in the default h files of a specific μC  even to control where your controller should look for a ROM at startup.You may plug your own ROM externally and just by ROM_whatever_function() reference in your code to read the external 'ROM' function instead of the internal chip's ROM default function. On the other hand, many μC manufacturers for their own businesses and/or specific technical reasons do hide some code somewhere in the addressable  space. That code, along with the R/O (reserved) bits on the chip's register memory space do compose what once we used to call 'Undocumented xxxxx', where xxxxx the name of the OS. Who is the one that does not remember the Undocumented DOS 'bible' of Schulman back at the early 90's and the 'war' around the famous INT-13. Even today, Linux although open, Windows and various Linux/UNIX variant OSs do have many-MANY undocumented features. Among all the possibly undocumented features, the most important according to my opinion are the BIOS/ROM undocumented functionalities, if they exist of course.

John

Hello Bob and we thank you for clarifying the issue. For anyone who would like to have the big picture of the GEL files space, the directory is at \ccsv7\ccs_base\emulation\gel

John