Hello.
Each of the C and Ada frontends has a different interpretation of the some kind of double constants.

Reproducing:
Write the same small double constants for each language.

double1.c
--------
const double d_min = 0x0.3ffffffffffffeP-1072;
--------

double2.ads
--------
package double2 is
   d_min : constant Long_Float := 16#0.3ffffffffffffe#e-268;
end double2;
--------

(Note: These constants are the hexadecimal of __DBL_DENORM_MIN__ and wanted to be rounded to the minimal value of double. The precise value is 0x0.4P-1072, but __DBL_DENORM_MIN__ is a written as decimal, so these constants are got from it by the conversion. This value is unimportant because perhaps this bug can be reproduced with other values.)

Compile them.

$ gcc -W -Wall -S double1.c
$ gcc -W -Wall -S double2.ads
double2.ads:2:35: warning: floating-point value underflows to 0.0

Ada frontend reports the underflow. C frontend does not.
And compare double1.s and double2.s.

double1.s
--------
	.text
	.globl _d_min
	.const
	.align 3
_d_min:
	.long	1                   # <- It has been rounded.
	.long	0
	.ident	"GCC: (GNU) 10.1.0"
	.subsections_via_symbols
--------

double2.s
--------
	.text
	.globl _double2_E
	.data
	.align 1
_double2_E:
	.space 2
	.globl _double2__d_min
	.const
	.align 3
_double2__d_min:
	.space 8                    # <- It has been truncated.
	.ident	"GCC: (GNU) 10.1.0"
	.subsections_via_symbols
--------

I first noticed it in the FreeBSD 32bit. FreeBSD 32bit has the lesser precision of long double than other environments. However, then I tried it in FreeBSD 64bit, Linux, and MacOSX and it is reproducible too.