--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-17 21:32 ---
Looks like directives.c:parse_include is not handling the
dependency case correctly.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:19 2007
New Revision: 127598
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127598
Log:
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #14 from paolo at gcc dot gnu dot org 2007-08-17 21:38 ---
Subject: Bug 32190
Author: paolo
Date: Fri Aug 17 21:38:40 2007
New Revision: 127599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127599
Log:
2007-08-17 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #15 from pcarlini at suse dot de 2007-08-17 21:40 ---
Already fixed in 4_2-branch and mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from aaw at gcc dot gnu dot org 2007-08-17 21:42 ---
Subject: Bug 31749
Author: aaw
Date: Fri Aug 17 21:42:38 2007
New Revision: 127600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127600
Log:
PR c++/31749
gcc/cp/
* name-lookup.c
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-17 22:08 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Subject: Bug 28989
Author: pinskia
Date: Fri Aug 17 22:14:47 2007
New Revision: 127603
URL:
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-17 22:15
---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
This C++ test case works with gcc 4.1.1. With gcc 4.2 and with mainline it
gets an inexplicable error.
typedef void v;
typedef v (*pf)(v);
foo.cc:2: error: anonymous has incomplete type
foo.cc:2: error: invalid use of v
--
Summary: C++ error on valid code: anonymous has
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-17 23:33 ---
This is not valid code.
*** This bug has been marked as a duplicate of 9278 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-08-17 23:33
---
*** Bug 33101 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Source code:
--
volatile int i;
int j;
int testme(void)
{
return i = 1;
}
int testme2(void)
{
return j = 1;
}
--
Compiler command line: cc -S -O torvalds.c
--
Expected results: volatile accesses not moved past sequence points,
optimization
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
00:11 ---
Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid
generating unnecessary code.
--
paulmck at linux dot vnet dot ibm dot com changed:
What|Removed
--- Comment #3 from segher at kernel dot crashing dot org 2007-08-18 00:12
---
(In reply to comment #1)
volatile != atomic.
And that is relevant why? Paul is perfectly aware of this, btw.
There might be other reasons why GCC doesn't want to do this
optimisation, but this isn't one
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-18 00:12 ---
It is still the same issue.
*** This bug has been marked as a duplicate of 3506 ***
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-18 00:12
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-18 00:21 ---
omewhat also related, (void)x; still accesses memory when x is volatile --
I suppose this might be desirable, however.
It is because you say to load from x.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-18 00:05 ---
volatile != atomic.
*** This bug has been marked as a duplicate of 3506 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 00:05
---
*** Bug 33102 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from segher at kernel dot crashing dot org 2007-08-18 00:31
---
It is still the same issue.
*** This bug has been marked as a duplicate of 3506 ***
It isn't the same issue. The submitter of #3506 claimed the code
that GCC currently generates is incorrect, which
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:04 ---
(In reply to comment #4)
It is still the same issue.
Perhaps I am missing something, but I don't know of any hardware that would
react differently to this two-instruction sequence:
movli,
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-18 01:10 ---
One should note this is actually hard to do without changing the code for 3506
also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-18 01:11 ---
PS you should have reported this first to debian since you are using their
modified version of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-18 01:12 ---
s/debian/Ubuntu/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 01:13
---
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:21 ---
(In reply to comment #10)
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
The main concern on the recent LKML
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:23 ---
(In reply to comment #9)
s/debian/Ubuntu/
Please accept my apologies for skipping that step -- I wasn't aware of this.
Should I replicate this bug at Ubuntu, or is this strictly advice for future
bug
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-08-18 01:25
---
(In reply to comment #11)
The main concern on the recent LKML thread appeared to be code size rather
than
speed.
One should note this only helps CISC based processors, it will not help stuff
like PowerPC
--- Comment #2 from ian at airs dot com 2007-08-18 04:19 ---
Thanks for the explanation. That is new to me.
I am now going to reopen this bug because the error message is terrible. There
is no anonymous or incomplete type here. gcc should perhaps print something
like
error: invalid
This report was prompted by a mail on the lkml which was suggesting to
hand-craft memset: http://lkml.org/lkml/2007/8/17/309 . So I wondered if the
code generated for __builtin_memset was any good, and could be used instead of
hand-crafted code. I tested with (Debian) GCC 3.4.6, 4.1.3, 4.2.1, and
101 - 130 of 130 matches
Mail list logo
