Hi,
with this code-snippet below, some gcc's emit printf-format
warnings twice when including , but don't do so when
not including :
Example:
# i386-rtems4.10-gcc -Wall -c -o tmp.o tmp.c
tmp.c: In function 'main':
tmp.c:9: warning: format '%d' expects type 'int', but argument 2 has
type 'char *
FYI, the LLVM project just pushed out its 2.6 release:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-October/33.html
There is a lot of goodness in this release, which spanned 6 months
instead of the usual 3. Of particular interest to the GCC community
may be the 'DragonEgg' GCC p
[cross-posted to cygwin list]
Background for cygwin list: Dave discovered a problem running some of
the gcc tests. The tests were run in the "C" locale, but in so doing
they assumed an ascii encoding (specifically, that "'" would match ' in
test patterns -- but the program actually emitted those
On Wed, 2009-09-23 at 11:05 -0400, Jason Merrill wrote:
> On 09/23/2009 09:22 AM, Jerry Quinn wrote:
> > I'm not really sure how everything fits together here. Am I missing
> > something obvious?
>
> I notice that you're missing the fix_string_type that tinfo_name does.
> But I'd rather not dupl
> I thought about that too, but a -f flag would be passed to the
> middle-end, where it does not make any sense. We could make it a -f
> flag anyhow, of course, and just explicitly ignore it in the
> middle-end.
>
> Any opinions on the best user interface for this?
From an user interface point of
Paul Edwards wrote:
> > Are you running the top-level configure? (If you run a
> > subdirectory configure, e.g. the one in gcc/, directly,
> > things may not work correctly.)
>
> Yes I am.
>
> One other thing I did - I compiled the cross-compiler, and installed it.
>
> Then I wiped out the dir
"Zhang Lin" writes:
> class ACE_Message_Queue_NT;
> template
> ACE_Message_Queue_NT *ACE_Message_Queue_Factory::create_NT_message_queue
> (int max_threads)
> {
> ACE_Message_Queue_NT *tmp = 0;
>
> tmp = new ACE_Message_Queue_NT (max_threads);
>
> return tmp;
> }
>
> class ACE_Message_Queue_
Joseph S. Myers wrote:
> On Sat, 24 Oct 2009, Richard Guenther wrote:
>
>> The testsuite should run with C locale.
>
> Unfortunately it appears there are now some systems where C no longer
> implies ASCII, causing problems for predictability of output. So the
> testsuite may need to check the
Andrew Pinski wrote:
> On Fri, Oct 23, 2009 at 4:01 PM, Dave Korn
> wrote:
>>Hi everyone,
>>
>> Sorry for posting a dumb question, but it's not my strongest area: now that
>> cygwin is handling i18n and unicode and "all that stuff", I started seeing a
>> whole slew of test failures, e.g.:
>
If you use --disable-nls on the configure line, the intl directory
should be skipped ...
Ok, that's working.
The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h. Looking at the system.h,
On Sat, 24 Oct 2009, Richard Guenther wrote:
> The testsuite should run with C locale.
Unfortunately it appears there are now some systems where C no longer
implies ASCII, causing problems for predictability of output. So the
testsuite may need to check the host and use other host-specific nam
On Fri, Oct 23, 2009 at 4:01 PM, Dave Korn
wrote:
>
> Hi everyone,
>
> Sorry for posting a dumb question, but it's not my strongest area: now that
> cygwin is handling i18n and unicode and "all that stuff", I started seeing a
> whole slew of test failures, e.g.:
The .exp files should be setti
On Sat, Oct 24, 2009 at 1:01 AM, Dave Korn
wrote:
>
> Hi everyone,
>
> Sorry for posting a dumb question, but it's not my strongest area: now that
> cygwin is handling i18n and unicode and "all that stuff", I started seeing a
> whole slew of test failures, e.g.:
>
>> FAIL: g++.dg/debug/pr22514
Hi everyone,
Sorry for posting a dumb question, but it's not my strongest area: now that
cygwin is handling i18n and unicode and "all that stuff", I started seeing a
whole slew of test failures, e.g.:
> FAIL: g++.dg/debug/pr22514.C (test for errors, line 12)
> FAIL: g++.dg/debug/pr22514.C
On Fri, 23 Oct 2009, Eric Botcazou wrote:
> > I didn't find (or could construct) a single C or C++ testcase that
> > wasn't fine with the new default, so I switched it (IIRC the default
> > is disambiguating the most cases).
>
> Yes, the default is the optimistic answer and a few tests rely on it
On Fri, Oct 23, 2009 at 9:35 AM, Zhang Lin wrote:
> Sorry, maybe my representation is not quite clear.
> I mean that I didn't define ACE_HAS_NONSTATIC_OBJECT_MANAGER at all, so the
> preprocesser should not process "#elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER ==
> 0)", the following simple cpp can
It works no problem for me.
This is what I get:
$ gcc -Wall -o "Test.exe" "macro.cpp" -lstdc++ -s -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-compiler=c --enable-language=c
--prefix=/home/beyler/tmp/gcc-4.3.2/bin
Thread model: posix
gcc version 4.3.2 (
> I didn't find (or could construct) a single C or C++ testcase that
> wasn't fine with the new default, so I switched it (IIRC the default
> is disambiguating the most cases).
Yes, the default is the optimistic answer and a few tests rely on it:
FAIL: gcc.dg/tree-ssa/alias-18.c scan-tree-dump fr
Steven Bosscher writes:
> On Fri, Oct 23, 2009 at 8:21 PM, Ian Lance Taylor wrote:
>> Rafael Espindola writes:
>>
>>> 2009-10-23 Rafael Avila de Espindola
>>>
>>> * gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin from the
>>> command
>>> line.
>>
>> This is OK if it passes
On Fri, Oct 23, 2009 at 8:21 PM, Ian Lance Taylor wrote:
> Rafael Espindola writes:
>
>> 2009-10-23 Rafael Avila de Espindola
>>
>> * gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin from the command
>> line.
>
> This is OK if it passes bootstrap and if nobody objects in 24 hou
Rafael Espindola writes:
> 2009-10-23 Rafael Avila de Espindola
>
> * gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin from the command
> line.
This is OK if it passes bootstrap and if nobody objects in 24 hours.
Thanks.
Ian
Hello,
I have encountered an issue when building ACE with MinGW and GCC 4.4.1.
The following example can reproduce the issue:
==
main.cpp
==
class ACE_Message_Queue_NT;
template
class ACE_Message_Queue_Factory
{
public:
static ACE_Message_Queue_NT *create_NT_message_queue (int max
Sorry, maybe my representation is not quite clear.
I mean that I didn't define ACE_HAS_NONSTATIC_OBJECT_MANAGER at all, so the
preprocesser should not process "#elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER ==
0)", the following simple cpp can reproduce the problem.
Test.cpp
==
#if !defined (A
> Working on it.
The attached patch solves the problem. It is not very elegant to
remove -use-linker-plugin from the command line, but it is not used after
linking.
2009-10-23 Rafael Avila de Espindola
* gcc.c (LINK_COMMAND_SPEC): Remove -use-linker-plugin from the command
> I changed this default to false somewhen in the past. There was a
> big fat comment there on the alias-improvements branch (where I
> wondered if returning false would be a safe thing to do).
>
> I didn't find (or could construct) a single C or C++ testcase that
> wasn't fine with the new defaul
2009/10/23 Ian Lance Taylor :
> I noticed that the -use-linker-plugin option seems to be passed to the
> linker. This is because LINK_COMMAND_SPEC includes %{u*}. And that
> is because -uSYMBOL is a documented linker option.
>
> The effect is that the linker creates an undefined reference to the
Paul Edwards wrote:
> Ok, perhaps this error was because when I hit errors in intl,
> which I've never used before, I just went to the gcc directory and
> did a make.
>
> Regardless, I added a stack of touch xxx.o in the intl directory
> after the failure of the first make, which allowed me to do
I noticed that the -use-linker-plugin option seems to be passed to the
linker. This is because LINK_COMMAND_SPEC includes %{u*}. And that
is because -uSYMBOL is a documented linker option.
The effect is that the linker creates an undefined reference to the
symbol "se-linker-plugin". Any user un
"Paul Edwards" writes:
> The next thing I hit was that genmodes didn't compile because
> there were conflicts between the strsignal function in the
> Linux include files and the system.h. Looking at the system.h,
> it was including things in because it thought that the prototypes
> didn't exist.
Mohamed Shafi writes:
> The internal doc says :
>
> — Target Hook: bool TARGET_CAN_INLINE_P (tree caller, tree callee)
>
> This target hook returns false if the caller function cannot
> inline callee, based on target specific information. By default,
> inlining is not allowed if the callee fu
Quoting Mohamed Shafi :
I have implemented the above solution and it works. I have to support
the same for DF also. But with DF i have a problem with the
constraints. My target generates code for both big and little endian.
The ABI specifies that when a 64bit value is passed as an argument
they a
As to the pex-unix.c, you certainly should provide a MVS-specific
version of the PEX callbacks. They are selected in configure.ac:
# Figure out which version of pexecute to use.
case "${host}" in
*-*-mingw* | *-*-winnt*) pexecute=pex-win32.o ;;
*-*-msdosdjgpp*) pexecute=pex-
2009/9/14 Richard Henderson :
> Another thing to look at, since you have hand-written routines and may be
> able to specify that e.g. only a subset of the normal call clobbered
> registers are actually modified, is to leave the call as a "compare" insn.
> Something like
>
> (define_insn "*cmpsf"
>
2009/10/23 Zhang Lin :
> Hello,
> I have encountered an issue when building ACE with MinGW and GCC 4.4.1
> The following macro was not accepted by the preprocessor and it reported such
> an error: "error: operator '==' has no left operand".
>
> #if !defined (ACE_HAS_NONSTATIC_OBJECT_MANAGER)
> # d
Hello,
I have encountered an issue when building ACE with MinGW and GCC 4.4.1
The following macro was not accepted by the preprocessor and it reported such
an error: "error: operator '==' has no left operand".
#if !defined (ACE_HAS_NONSTATIC_OBJECT_MANAGER)
# define ACE_HAS_NONSTATIC_OBJECT_MANAG
On Fri, 23 Oct 2009, Eric Botcazou wrote:
> Hi Richard,
>
> I just (re-)discovered that the new TBAA machinery is quite aggressive and
> breaks cases that used to work in Ada (-O2 testcase for SPARC64 attached).
>
> The problem boils down to this:
>
> D.1416_1 = (struct p__rec &) &r.F;
> r
Hi Richard,
I just (re-)discovered that the new TBAA machinery is quite aggressive and
breaks cases that used to work in Ada (-O2 testcase for SPARC64 attached).
The problem boils down to this:
D.1416_1 = (struct p__rec &) &r.F;
r.F = ...
... = D.1416_1->d;
DSE computes that the store to
Hi,
The internal doc says :
— Target Hook: bool TARGET_CAN_INLINE_P (tree caller, tree callee)
This target hook returns false if the caller function cannot
inline callee, based on target specific information. By default,
inlining is not allowed if the callee function has function specific
ta
38 matches
Mail list logo
