public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/51741] New: complicatet brakets wont compile
@ 2012-01-03 15:07 digsag at web dot de
2012-01-03 15:19 ` [Bug c/51741] " rguenth at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: digsag at web dot de @ 2012-01-03 15:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
Bug #: 51741
Summary: complicatet brakets wont compile
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: digsag@web.de
flowing structure:
typedef struct{//branch
char what;
void *where; //cast to knot *
}branch;
typedef struct{//knot
void *father; //cast to knot *
branch *branches;
}knot;
adressing a knot** to hand it to a subfun wont compile:
// (*pos)
// ( .branches)
// ( [i])
// ( .where)
// ((knot*) )
// (& )
(&((knot*)((((*pos).branches)[i]).where)))
(compiler sas lvaluve needed for unary & operator)
but
// (*pos)
// ( .branches)
// ( [i])
// ( .where)
// (& )
// ((knot**) )
((knot**)(&((((*pos).branches)[i]).where)))
((knot**)(&((((*pos).branches)[i]).where)))
will.
both seem like legal C to me.
another one:
// (*pos)
// ( .branches)
// ( [0])
// ( .where)
// ((knot*) )
// ( .father)
(((knot*)((((*pos).branches)[0]).where)).father)=pos;
won't compile .
compiler thinks I try to adress .father for something thats not a structure or
a union. even though I castet it to a knot* before trying to adress .father.
yours
stfu&thnk
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
@ 2012-01-03 15:19 ` rguenth at gcc dot gnu.org
2012-01-03 15:21 ` digsag at web dot de
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-03 15:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 15:18:34 UTC ---
as soon as you cast the .where pointer to some other type it converts to
an rvalue. Use (knot*)&(....where) instead of &(knot *)(...where).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
2012-01-03 15:19 ` [Bug c/51741] " rguenth at gcc dot gnu.org
@ 2012-01-03 15:21 ` digsag at web dot de
2012-01-03 15:23 ` digsag at web dot de
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: digsag at web dot de @ 2012-01-03 15:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
--- Comment #2 from stfu&thnk <digsag at web dot de> 2012-01-03 15:21:26 UTC ---
I fail &secon one. forgot a * -.-
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
2012-01-03 15:19 ` [Bug c/51741] " rguenth at gcc dot gnu.org
2012-01-03 15:21 ` digsag at web dot de
@ 2012-01-03 15:23 ` digsag at web dot de
2012-01-03 15:25 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: digsag at web dot de @ 2012-01-03 15:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
--- Comment #3 from stfu&thnk <digsag at web dot de> 2012-01-03 15:23:12 UTC ---
(In reply to comment #1)
> as soon as you cast the .where pointer to some other type it converts to
> an rvalue. Use (knot*)&(....where) instead of &(knot *)(...where).
I don't know how the first one is non-valid C. seems valid in my eyes...
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
` (2 preceding siblings ...)
2012-01-03 15:23 ` digsag at web dot de
@ 2012-01-03 15:25 ` redi at gcc dot gnu.org
2012-01-03 15:47 ` digsag at web dot de
2012-01-03 15:53 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-01-03 15:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-03 15:25:32 UTC ---
The bug reporting guidelines at http://gcc.gnu.org/bugs/ ask for the following
which you have not provided:
* the exact version of gcc
* the exact command line
* the complete preprocessed source, not some code snippets (what is pos?)
(In reply to comment #0)
> (&((knot*)((((*pos).branches)[i]).where)))
>
> (compiler sas lvaluve needed for unary & operator)
The compiler is correct. The cast to (knot*) creates an rvalue, so you cannot
take its address.
> ((knot**)(&((((*pos).branches)[i]).where)))
Here you take the address of an lvalue, then cast it to (knot**), that's legal.
> will.
> both seem like legal C to me.
No, the first one is not. The bug is in your code, not GCC.
> (((knot*)((((*pos).branches)[0]).where)).father)=pos;
>
> won't compile .
> compiler thinks I try to adress .father for something thats not a structure or
> a union. even though I castet it to a knot* before trying to adress .father.
Maybe you mean ->father not .father.
Just because your code doesn't compile, that doesn't mean it's a GCC bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
` (3 preceding siblings ...)
2012-01-03 15:25 ` redi at gcc dot gnu.org
@ 2012-01-03 15:47 ` digsag at web dot de
2012-01-03 15:53 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: digsag at web dot de @ 2012-01-03 15:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
--- Comment #5 from stfu&thnk <digsag at web dot de> 2012-01-03 15:47:08 UTC ---
yeah i just realised how the second one was a fail of my side.
but I didn't realze the rvalue lvalue stuff.
thanx for the help, and please don't go all pissed off I didn't want to insult
you...
but well if you feel like an adult flaming at noobs, please go on :-P
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c/51741] complicatet brakets wont compile
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
` (4 preceding siblings ...)
2012-01-03 15:47 ` digsag at web dot de
@ 2012-01-03 15:53 ` redi at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2012-01-03 15:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51741
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-03 15:53:13 UTC ---
noone's insulted and noone's flaming, but in future please follow the bug
reporting guidelines (and maybe check with someone who knows C well before
assuming the compiler is wrong, e.g. ask on a newsgroup or on IRC channel for
the C language)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-01-03 15:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-03 15:07 [Bug c/51741] New: complicatet brakets wont compile digsag at web dot de
2012-01-03 15:19 ` [Bug c/51741] " rguenth at gcc dot gnu.org
2012-01-03 15:21 ` digsag at web dot de
2012-01-03 15:23 ` digsag at web dot de
2012-01-03 15:25 ` redi at gcc dot gnu.org
2012-01-03 15:47 ` digsag at web dot de
2012-01-03 15:53 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).