Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On 7 December 2011 20:14, Christian Joensson wrote: > I am trying to build gcc trunk on cygwin (with the snapshot of > 20111207) and get this: > > /usr/local/src/trunk/objdir.withada/./prev-gcc/g++ > -B/usr/local/src/trunk/objdir.withada/./prev-gcc/ > -B/usr/i686-pc-cygwin/bin/ -nostdinc++ > -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs > -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs > -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin > -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include > -I/usr/local/src/trunk/gcc/libstdc++-v3/libsupc++ > -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs > -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs > -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -fno-common -Wno-error -DHAVE_CONFIG_H -I. -Iada > -I/usr/local/src/trunk/gcc/gcc -I/usr/local/src/trunk/gcc/gcc/ada > -I/usr/local/src/trunk/gcc/gcc/../include > -I/usr/local/src/trunk/gcc/gcc/../libcpp/include -I/usr/include > -I/usr/include -I/usr/local/src/trunk/gcc/gcc/../libdecnumber > -I/usr/local/src/trunk/gcc/gcc/../libdecnumber/bid -I../libdecnumber > /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o > In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0, > from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107: > /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)': > /usr/include/sys/wait.h:77:61: error: declaration of C function 'int > __wait_status_to_int(const wait&)' conflicts with > /usr/include/sys/wait.h:75:12: error: previous declaration 'int > __wait_status_to_int(int)' here > /usr/include/sys/wait.h: In function 'pid_t wait(wait*)': > /usr/include/sys/wait.h:81:40: error: declaration of C function 'pid_t > wait(wait*)' conflicts with > /usr/include/sys/wait.h:37:7: error: previous declaration 'pid_t > wait(__wait_status_ptr_t)' here > /usr/include/sys/wait.h: In function 'pid_t waitpid(pid_t, wait*, int)': > /usr/include/sys/wait.h:83:71: error: declaration of C function 'pid_t > waitpid(pid_t, wait*, int)' conflicts with > /usr/include/sys/wait.h:38:7: error: previous declaration 'pid_t > waitpid(pid_t, __wait_status_ptr_t, int)' here > /usr/include/sys/wait.h: In function 'pid_t wait3(wait*, int, rusage*)': > /usr/include/sys/wait.h:85:81: error: declaration of C function 'pid_t > wait3(wait*, int, rusage*)' conflicts with > /usr/include/sys/wait.h:39:7: error: previous declaration 'pid_t > wait3(__wait_status_ptr_t, int, rusage*)' here > /usr/include/sys/wait.h: In function 'pid_t wait4(pid_t, wait*, int, > rusage*)': > /usr/include/sys/wait.h:87:94: error: declaration of C function 'pid_t > wait4(pid_t, wait*, int, rusage*)' conflicts with > /usr/include/sys/wait.h:40:7: error: previous declaration 'pid_t > wait4(pid_t, __wait_status_ptr_t, int, rusage*)' here this seems to me to be fixed, as of cygwin snapshot 20111209 I no longer get this specific error. -- Cheers, /ChJ
warn about deprecated access declarations
Hi,
According to § 11.3/1 from c++98, access delarations are deprecated:
The access of a member of a base class can be changed in the derived
class by mentioning its qualified-id in the derived class declaration.
Such mention is called an access declaration. The effect of an access
declaration qualified-id; is defined to be equivalent to the
declaration usingqualified-id; [Footnote: Access declarations are
deprecated; member using-declarations (7.3.3) provide a better means
of doing the same things. In earlier versions of the C++ language,
access declarations were more limited; they were generalized and made
equivalent to using-declarations - end footnote]
Consequently, I propose to deprecate them with a warning, as clang already does.
So that you get a warning for the following code:
struct A { int i; };
struct B : A
{
A::i; // <- warning here
};
warning: access declarations are deprecated; employ using declarations
instead [-Wdeprecated]
The warning is trivial to avoid, just add the keyword 'using' before
the access declaration.
Before adjusting the whole testsuite, I would like to know if there is
agreement to do it at stage 3.
The patch is really simple: (it does not include yet testsuite adjustements)
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 182209)
+++ gcc/cp/parser.c (working copy)
@@ -18900,7 +18900,11 @@ cp_parser_member_declaration (cp_parser*
parser->colon_corrects_to_scope_p = false;
if (cp_parser_using_declaration (parser, /*access_declaration=*/true))
-goto out;
+{
+ warning (OPT_Wdeprecated, "access declarations are deprecated; "
+ "employ using declarations instead");
+ goto out;
+}
/* Parse the decl-specifier-seq. */
decl_spec_token_start = cp_lexer_peek_token (parser->lexer);
--
Fabien
Re: warn about deprecated access declarations
On 11 December 2011 22:22, Fabien Chêne wrote:
>
> Consequently, I propose to deprecate them with a warning, as clang already
> does.
> So that you get a warning for the following code:
>
> struct A { int i; };
> struct B : A
> {
> A::i; // <- warning here
> };
>
> warning: access declarations are deprecated; employ using declarations
> instead [-Wdeprecated]
Whether or not it's suitable for stage 3, "employ" feels a bit clunky
in this context, how about "access declarations are deprecated in
favour of using-declarations" ?
Ad: Fix PR middle-end/45416, missing opt for (a&(1<
Bringing this over from gcc-patches@
Jakub Jelinek wrote:
On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote:
No, not OK.
This leads to unacceptable code for devices that cannot shift easily like,
e.g.AVR. This target can only shift by 1 and shifts with big offsets have
to be performed by means of a loop at runtime.
Andrew's patch only restored what GCC has been doing before.
If this is too expensive on AVR, you should just arrange in the backend to
combine that
((x>>C)&1) != 0
into more efficient code sequence,
Would you please outline how to do that?
Suppose the following C code:
char test_bit (long long x)
{
if (x & 0x400)
return 1;
else
return 0;
}
Notice that with the patch, optabs generate __lshrdi3 libgcc call.
So you will have to get rid of the libgcc call.
Without the patch, the generated code is 3 instructions:
test_bit:
ldi r24,lo8(1) ; 22 *movqi/2[length = 1]
sbrs r19,2 ; 32 *sbrx_branchqi [length = 2]
ldi r24,lo8(0) ; 33 *movqi/1[length = 1]
.L2:
ret ; 61 return [length = 1]
Situations for other modes are not better.
otherwise people who write
if ((x >> 18) & 1)
bar ();
in the source will get suboptimal code.
Jakub
Well, that just depends on what people you care for and what people you
ignore...
I still don't see why optimizing code for platform X is allowed to lead
to code bloat for platform Y.
The problem is:
* There is no canonical representation for "extract bit" or "move bit"
or "test bit" in the tree passes.
* tree -> RTL lowering does not care for RTX costs for the
different ways "testing a bit" etc. can be represented.
If there was a canonical representation of these operations, a backend
wouldn't even notice if the tree passes chose a different, more
convenient canonicalization.
The very problem is obviously that various ways to extract/test/move a
bit are not worked out during tree -> RTL expansion and that writing RTX
costs is paper waste.
What you are saying is: "Just change your backend if the code gets bad."
Maybe next week there is yet another change for platform Z and operation
Q. Again, the backend needs to be reworked and expand to be reverse
engineered to reveal what is this week's favourite style of expanding Q?
Really, if this is how architectural goal or development roadmap looks
like, then contributing to GCC is just waste of time.
Johann
Re: Ad: Fix PR middle-end/45416, missing opt for (a&(1<
On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay wrote: > If there was a canonical representation of these operations, a backend > wouldn't even notice if the tree passes chose a different, more convenient > canonicalization. The problem is not just the canonicalization but rather there is a problem of deciding which regression is important and how to fix it. Fixing this regression was easy as it just meant to turn back on the optimization that was there already. So after fixing this regression, we have another regression with the AVR back-end. I bet the best way to fix this is to ask the back-end what is the cost of doing a shift and if it is greater than doing an and with a setcc, then we should do the and/setcc rather than a shift with the and. It is not hard to add a target hook for this case, I can do it if the AVR folks think it would be useful. Thanks, Andrew Pinski
Re: Ad: Fix PR middle-end/45416, missing opt for (a&(1<
On Sun, 11 Dec 2011, Andrew Pinski wrote:
> On Sun, Dec 11, 2011 at 3:13 PM, Georg-Johann Lay wrote:
> > If there was a canonical representation of these operations, a backend
> > wouldn't even notice if the tree passes chose a different, more convenient
> > canonicalization.
>
> The problem is not just the canonicalization but rather there is a
> problem of deciding which regression is important and how to fix it.
There *is* a canonical RTL expression: "Equality comparisons of
a group of bits (usually a single bit) with zero will be written
using @code{zero_extract} rather than the equivalent @code{and}
or @code{sign_extract} operations." See e.g. cris.md "*btst" or
m68k.md (the last two zero_extract after "Recognizers for btst
instructions"; lots of variants there which could be reduced
to two using the "enabled" attribute AFAICT).
> Fixing this regression was easy as it just meant to turn back on the
> optimization that was there already. So after fixing this regression,
> we have another regression with the AVR back-end. I bet the best way
> to fix this is to ask the back-end what is the cost of doing a shift
> and if it is greater than doing an and with a setcc, then we should do
> the and/setcc rather than a shift with the and. It is not hard to add
> a target hook for this case, I can do it if the AVR folks think it
> would be useful.
If tree -> rtl doesn't emit or at least try the canonical RTL
first, then that's the problem.
brgds, H-P
Re: warn about deprecated access declarations
2011/12/11 Jonathan Wakely :
> On 11 December 2011 22:22, Fabien Chêne wrote:
>>
>> Consequently, I propose to deprecate them with a warning, as clang already
>> does.
>> So that you get a warning for the following code:
>>
>> struct A { int i; };
>> struct B : A
>> {
>> A::i; // <- warning here
>> };
>>
>> warning: access declarations are deprecated; employ using declarations
>> instead [-Wdeprecated]
>
> Whether or not it's suitable for stage 3, "employ" feels a bit clunky
> in this context, how about "access declarations are deprecated in
> favour of using-declarations" ?
Native spoker's suggestions are always very welcome, thanks !
(I was just trying to avoid using "use" ...)
--
Fabien
