--- Comment #2 from rschiele at gmail dot com 2008-12-30 06:07 ---
It works for you? This is weired!
Just tried it with current trunk again and it does still show exactly the same
error there.
--
rschiele at gmail dot com changed:
What|Removed
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33789
: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rschiele at gmail dot com
Target Milestone: ---
Created attachment 40487
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041
--- Comment #3 from Robert Schiele ---
If you point me to the specific patch that you have in mind I can in parallel
already test whether besides the test case I provided it also fixes the
original problem this was detected with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041
--- Comment #5 from Robert Schiele ---
Thanks! I can confirm that this also fixes the original problem for all cases
we observed so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Robert Schiele changed:
What|Removed |Added
CC||rschiele at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67738
Robert Schiele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: rschiele at gmail dot com
Target Milestone: ---
Trying to demangle the symbol
_ZNK6Common15ConvertingRangeIN5boost12range_detail17transformed_rangeIZN1a1b1cEbEUljE_KSt6vectorIjSaIjEcvT_IS7_INS4_1dESaISF_v
causes an
ity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rschiele at gmail dot com
I found a case where gcc diagnostic "array subscript is below/above array
bounds" is wrong in my opinion. I simplified the test case as much as
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
--- Comment #3 from rschiele at gmail dot com 2007-01-14 02:21 ---
Andrew, it does not help to initialize in init_spec() because init_spec() is
only called when there is _no_ spec file found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
--- Comment #4 from rschiele at gmail dot com 2007-01-14 03:12 ---
What about just calling init_spec() _allways_ _before_ reading the default
specs file instead of calling it only when there is no default specs file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
--- Comment #6 from rschiele at gmail dot com 2007-01-14 08:03 ---
Agreed, but why shouldn't we change the special handling of the default specs
file as suggested in comment #4? I can't see why we should enforce people to
specify _full_ information in the default specs file if
--- Comment #7 from rschiele at gmail dot com 2007-01-14 13:52 ---
Created an attachment (id=12904)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12904&action=view)
new version of the fix
This implements my new suggestion on how to fix this. Any comments?
--
rschiele a
14 matches
Mail list logo