--- Comment #13 from jakub at gcc dot gnu dot org 2007-03-19 23:28 ---
Subject: Bug 30762
Author: jakub
Date: Mon Mar 19 23:28:33 2007
New Revision: 123075
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123075
Log:
PR c/30762
* c-typeck.c (convert_for_assignment)
--- Comment #15 from manu at gcc dot gnu dot org 2007-03-19 23:35 ---
Andrew, you have Paolo and Gabriel expressing that the warning should not be
emitted because the code is generated. Then you close as wontfix. Sometimes I
don't understand you at all.
--
http://gcc.gnu.org/bugzill
--- Comment #16 from gdr at cs dot tamu dot edu 2007-03-19 23:40 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| But the user can see the code,
Andrew --
When you don't understand an issue, ple
--- Comment #17 from pcarlini at suse dot de 2007-03-19 23:43 ---
WONTFIX is simply ridicolous.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #1 from wilson at gcc dot gnu dot org 2007-03-19 23:49 ---
I'm not a C++ expert, so I'm not the right person to say for sure, but this
looks like an accidental bug to me. There were patches added to change the
bitfield type representation, the is_bitfield_expr_with_lowered_t
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 23:52 ---
Created an attachment (id=13236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13236&action=view)
proposed cp/call.c patch for suspected standard_conversion bug
This is the proposed patch I referred to in my an
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 00:24 ---
> D.1879_8 was replaced by 31, ignoring the fact that the value should have been
> truncated to 15 when assigned to s.b4.
The front-end should have truncated that to 15. Which front-end are you using,
C or C++?
-
--- Comment #3 from TabonyEE at austin dot rr dot com 2007-03-20 00:39
---
C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-03-20 00:41
---
Reply to comment #8: that was my take on this, that ifort is correct. It
passed my intuitive sense of it. Non-advancing means what it says so that the
subsequent write must continue from there and overwrite what
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-20 00:44
---
I think we can do the option case fairly straight forward, after we get some of
the more serious problems fixed. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
de 2007-03-19 22:59 ---
> (In reply to comment #19)
>
> Jerry,
>
> I tried FX's snapshot from today (20070319) and the example
> above works. A somewhat more twisted example which I have
> not yet been able to reduce leads to an IOSTAT value of 5001
> (BTW: what
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-03-20 02:20
---
Error 5001 would be ERROR_OPTION_CONFLICT. There are 18 different errors
associated with that code. To find out which one, you must remove the iostat
from the offending line so that gfortran will print the erro
--- Comment #3 from kargl at gcc dot gnu dot org 2007-03-20 03:09 ---
Tobi, this is a bogus request and the PR should be
closed. The standard does not require left to right
evaluation. It is the responsibility of the programmer
to know what she is doing. I think this should be
closed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #14 from spark at gcc dot gnu dot org 2007-03-20 04:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 04:45:14 2007
New Revision: 123083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123083
Log:
2007-03-19 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--- Comment #15 from spark at gcc dot gnu dot org 2007-03-20 04:50 ---
Fixed in 4.1, 4.2 and 4.3
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 05:54 ---
Closing again, this time as won't fix. Fortran is not C/C++/Java. This case
if you get -fbounds-check failing, then the bug is in the code and not in
Gfortran. Yes the standard might allow for short circuiting but
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Keywords||rejects-valid
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 06:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 06:34 ---
Related to PR 20115. Though in this case we only get VUSE as all the variables
listed are really const which is why if you add a function which sets
for_stack_ptr, it works as for_stack_ptr is no longer const.
This
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 06:40 ---
Related to PR 26534.
Anyways the bug is in the front-end, We most likely have a mismatch type also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
msgl-check.c: In function 'plural_help':
msgl-check.c:194: error: unrecognizable insn:
(insn 41 40 42 4 msgl-check.c:179 (set (reg:SI 75)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.plural_table") ) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
msgl-check.c:194: i
--- Comment #1 from arcangelpip at hotmail dot com 2007-03-20 07:18 ---
Created an attachment (id=13237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13237&action=view)
Preprocessed output from the file.
Added the preprocessed output.
--
http://gcc.gnu.org/bugzilla/show_bug.
101 - 123 of 123 matches
Mail list logo
