[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2012-02-10 Thread ktietz at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11612 Kai Tietz ktietz at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2010-07-10 Thread ktietz at onevision dot com
--- Additional Comments From ktietz at onevision dot com 2010-07-10 16:21 --- The solution for this issue is to quote the name by '. This prevents that the .def file parser treats the symbol name as keyword. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11612 --- You are

[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2010-07-09 Thread ktietz at onevision dot com
--- Additional Comments From ktietz at onevision dot com 2010-07-09 11:56 --- The failure isn't reasoned by shift reduces. The underlying problem you see here is, that for IDs the keywords aren't recognized. So symbols named 'data', or 'BASE', etc aren't recognized by grammer. This

[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2010-07-04 Thread dougsemler at gmail dot com
--- Additional Comments From dougsemler at gmail dot com 2010-07-04 12:37 --- I'm reopening this bug: I believe the patch that fixed this in deffilep.y introduced a shift-reduce conflict that now fails to align properly any symbol that is listed in the tokens[] array on or about line

[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2010-05-26 Thread nickc at redhat dot com
--- Additional Comments From nickc at redhat dot com 2010-05-26 08:20 --- Hi Doug, I tried to reproduce this problem but could not. Would it be possible for you to upload the test.o file from your example ? Also please could you check to see if the problem still exists with the

[Bug ld/11612] New underscoring behavior can break -aligncomm directve

2010-05-26 Thread dougsemler at gmail dot com
--- Additional Comments From dougsemler at gmail dot com 2010-05-26 13:39 --- I believe this bug is now fixed at v1.33 of depfile.y that Kai checked in yesterday (allow leading . for symbol names in the parser). -- What|Removed |Added