Bug 54048 - Uninitialized input_location in front-end initialization
Summary: Uninitialized input_location in front-end initialization
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-20 12:26 UTC by Mikael Morin
Modified: 2013-06-27 09:17 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-27 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Morin 2012-07-20 12:26:12 UTC 
Valgrind gives errors of the following kind with gfortran 4.6.3 and 4.7.1.
Can't check 4.8.0 as valgrind chokes on it (illegal instruction). 

==16437== Conditional jump or move depends on uninitialised value(s)
==16437==    at 0x5C3571B: __GI___strcasecmp_l (in /lib64/libc-2.14.1.so)
==16437==    by 0x5BD62F2: __gconv_open (in /lib64/libc-2.14.1.so)
==16437==    by 0x5BE3279: _nl_find_msg (in /lib64/libc-2.14.1.so)
==16437==    by 0x5BE3A14: __dcigettext (in /lib64/libc-2.14.1.so)
==16437==    by 0xCADDE9: expand_location(unsigned int) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/f951)
==16437==    by 0x58A53D: pushdecl(tree_node*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/f951)
==16437==    by 0x5DAEFA: gfc_init_types() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/f951)
==16437==    by 0x58B506: gfc_init() (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/f951)
==16437==    by 0x8311BE: toplev_main(int, char**) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/f951)
==16437==    by 0x5BD53DC: (below main) (in /lib64/libc-2.14.1.so)
Comment 1 Dominique d'Humieres 2013-06-27 08:58:55 UTC 
Is this still present? If yes can tou provide a reproducer?
Comment 2 Mikael Morin 2013-06-27 09:17:03 UTC 
(In reply to Dominique d'Humieres from comment #1)
> Is this still present? If yes can tou provide a reproducer?

No. As far as I remember, it used to happen on any testcase, for example:

!!!
end
!!!

It seems to work now.  Valgrind reports errors, but they seem to be deep down the middle-end, and unrelated to this.  Closing.