Re: [ARM optimization back-end] Strange bug in MySQL
On Thu, Apr 26, 2007 at 03:28:26PM +0200, Emmanuel Fleury wrote: > But if the bug disappear when -O2 is turned off, I do suspect > (*eventually*) some problem in the ARM back-end... Am I right ? Probably/maybe/possibly. It also could be the case that MySQL is doing something that invokes undefined behavior (aliasing or alignment bugs, for example) that just happens to work OK with the optimizer disabled, and then the optimize performs a legal transformation that causes the code to fail. -Jack
Re: zero and pointer conversions in g++
I believe the problem is that false (and bool()) have value 0, which is also a
pointer value in C (and in C++). C++ is attempting to do the least surprising
conversion, and in this case getting that 'wrong'. That is why test1 works and
test2 does not. I haven't bothered to check with the standard but I am fairly
certain what you are seeing is the expected type conversion for this case.
You can design around this by moving the special-case handling of strings in
Config::read into special-case handling in Variant::operator<<; that also
prevents the current situation where
config.read("a", std::string("a"));
config.read("b", Variant(std::string("b")));
result in different outputs, something which seems very counterintuitive to
me. I've attached some code I threw together to test some of these ideas, which
may be worth taking a glance at.
BTW, questions of this nature should probably be directed to the gcc-help list
rather than the main development mailing list.
-Jack
On Mon, Dec 26, 2005 at 02:04:52PM -0600, Thomas Braxton wrote:
> I have this test code that I think g++ is selecting the wrong function when
> the second argument is a zero. If compiled with HAVE_ASCII_DEFAULT 1 it
> selects read(const char*, const char*) instead of read(const char*, const
> Variant&), for test2a/test3a. If compiled with HAVE_ASCII_DEFAULT 0
> compilation fails because test2a/test3a are ambiguous. Shouldn't all of the
> tests select the Variant function, or am I missing something? Why do I have
> to explicitly create a Variant when the argument is zero?
>
> Tested w/ g++ 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) and 4.0.1 (self compiled)
>
> TIA,
> Thomas
>
> PS please CC as I'm not subscribed
[attached code snipped]
#include
#include
#include
#include
class type
{
public:
enum type_code { Bool, Int, String, Pointer, None };
std::string as_string() const;
type(bool b2) : we_are(Bool), b(b2), i(), s(), p(0) {}
type(int i2) : we_are(Int), b(), i(i2), s(), p(0) {}
type(std::string s2) : we_are(String), b(b), i(), s(s2), p(0) {}
type(char* s2) : we_are(String), b(b), i(), s(s2), p(0) {}
type(void* p2) : we_are(Pointer), b(b), i(), s(), p(p2) {}
type() : we_are(None), b(), i(), s(), p(0) {}
private:
type_code we_are;
bool b;
int i;
std::string s;
const void* p;
};
std::string type::as_string() const
{
std::stringstream buf;
switch(we_are)
{
case None: buf << "nil"; break;
case Int: buf << "int(" << i << ")"; break;
case String: buf << "string(\"" << s << "\")"; break;
case Pointer: buf << "pointer(" << p << ")"; break;
case Bool: buf << "bool(" << (b ? "true" : "false") << ")"; break;
default:
buf << "";
}
return buf.str();
}
std::ostream& operator<<(std::ostream& out, const type& t)
{
out << t.as_string();
return out;
}
int main()
{
std::map types;
types["type(nil)"] = type();
types["type(true)"] = type(true);
types["type(false)"] = type(false);
types["type(bool())"] = type(bool());
types["type(int())"] = type(int());
types["type(0)"] = type(0);
types["type((void*)0)"] = type((void*)0);
types["type((int*)0)"] = type((int*)0);
types["type(1001)"] = type(1001);
types["type(\"foo\")"] = type("foo");
types["type(std::string(\"bar\"))"] = type(std::string("bar"));
types["type(&types)"] = type(&types);
std::map::const_iterator j;
for(j = types.begin(); j != types.end(); j++)
std::cout << j->first << " is " << j->second << std::endl;
}
Re: ggc 3.3.2 on aix 5.2 long long type?
The general problem is probably the same as PR 13358 (one that I've wished was fixed for a while, myself). Unfortunately there is no way as of now to disable this warning, short of disabling warnings entirely. -Jack On Tue, Jan 10, 2006 at 01:18:11PM -0800, sabreman (sent by Nabble.com) wrote: > > I getting the following warning with unsigned long long world_wide_name; > (scsi_buf.h). > > warning : integer constant is too large for "long" type. > > Is there a swich I need to add? > > I am just using: gcc -o test test.c > > Thanks! > -- > View this message in context: > http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2308440 > Sent from the gcc - Dev forum at Nabble.com. >
Re: How to implement "unsigned long long __rdtsc ()" for x86?
On Fri, Jan 16, 2009 at 09:35:33AM -0800, Andrew Thomas Pinski wrote: > On Jan 16, 2009, at 9:23 AM, "H.J. Lu" wrote: > >> Hi, >> >> I am trying to implement >> >> unsigned long long __rdtsc (void); >> >> for RDTSC as an intrinsic. It is easy to do it with asm statement. >> But I am having a hard time to implement it as a gcc builtin. >> The main problem is there is no input. It is impossible to write >> a proper RTL for it. Any suggestions? > > unspec_volatile? I don't see any issues with a no input unspec_volatile > the rs6000 backend uses that already. According to the info docs, the Alpha has __builtin_alpha_rpcc which doesn't take any inputs either, and should just call rpcc much as an rdtsc intrinsic would, so it may provide a more direct model. -Jack
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > A process can send a signal via kill. IOW, a malicious process can > *control when the process would be interrupted* in order to get it into > the signal handler with DF=1. If the malicious process can send a signal to another process, it could also ptrace() it. Which is more useful, if you wanted to be malicious? Jack
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote:
> Jack Lloyd wrote:
> >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> >>A process can send a signal via kill. IOW, a malicious process can
> >>*control when the process would be interrupted* in order to get it into
> >>the signal handler with DF=1.
> >
> >If the malicious process can send a signal to another process, it
> >could also ptrace() it. Which is more useful, if you wanted to be
> >malicious?
>
> 1) capabilities(7)
Ah you are right, I misinterpreted something from the man page
("non-root processes cannot trace processes that they cannot send
signals to") to mean something it did not (basically, that CAP_KILL
implied CAP_SYS_PTRACE, which from reading the kernel source is
clearly not the case...)
But still: so the threat here is of a malicious process with the
ability to send arbitrary signals to any process using CAP_KILL (since
in any other case when a process can send a signal, it can do much
more damage in other ways), which could leverage that into
(potentially) uid==0 using misexecuted code in a signal handler.
As a correctness issue, obviously this should be fixed/patched around,
if feasible. But as a security flaw? I'm not seeing much that is
compelling.
> 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1)
I don't understand how this is a problem - unless these setuid
programs, while not malicious, can be tricked into signalling a
process they did not intend to. (In which case they already have a
major bug, df bit being cleared or not).
-Jack
Re: Feature request - a macro defined for GCC
On Tue, Jul 01, 2008 at 05:34:17PM +, x z wrote: > > I think an important point was missed in the discussion. Some seem to focus > on the dishonest definition of __GNUC__ by non-GNU C compilers. That was not > my point. My point is that if __GNUC__ is defined by CPP, not the GNU C > compiler proper, (and this seems to be supported by the CPP Manual,) and any > (non-GNU) C compiler can use CPP, then those non-GNU C compilers would > "inadverdently" define __GNUC__ and lead people to believe that they are GNU > C. That is why I think the GNU C compiler should define a macro > independently from CPP. Or, alternatively, __GNUC__ should be defined by the > GCC compiler proper, not CPP. Perhaps you can use 'defined(__GNUC__) && !defined(__INTEL_COMPILER)' In www.intel.com/cd/software/products/asmo-na/eng/284736.htm (warning: a PDF, despite the .htm extension (!)): "A new option has been added, -gcc-sys, which is similar to -no-gcc, except that the GNU macros are only defined when preprocessing system include headers files, so these will compile correctly." Googling "Intel C++ __GNUC__" shows several major projects have been affected by this icc misfeature. -Jack
Re: Feature request - a macro defined for GCC
On Wed, Jul 02, 2008 at 03:47:49PM +0200, Vincent Lefevre wrote: > On 2008-07-02 00:12:33 +, Joseph S. Myers wrote: > > This internal binary no longer exists. Instead, there is a "cpp" > > binary installed in the user binary directory, which calls the "cc1" > > binary to do the same preprocessing as it does when compiling; that > > is, it has the same effect as "gcc -E". > > Not exactly: > > vin% cpp -dM /dev/null | wc -l > 128 > vin% gcc -E -dM /dev/null | wc -l > gcc.real: /dev/null: linker input file unused because linking not done > 0 > > Is it a bug of "gcc -E"? Not really, it just doesn't understand it needs to treat an empty file as C... instead you have to tell it so with -x c (wks9 ~)$ cpp -dM /dev/null | wc -l 86 (wks9 ~)$ gcc -E -dM /dev/null | wc -l gcc: /dev/null: linker input file unused because linking not done 0 (wks9 ~)$ gcc -E -x c -dM /dev/null | wc -l 86 (wks9 ~)$ gcc -E -x c++ -dM /dev/null | wc -l 92
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:17:43PM -0700, Joe Buck wrote: > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > > libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > > Is that OK to borrow code from coreutils which implements /bin/chmod > > to properly implement chmod? coreutils is under GPLv3 while libgfortran > > is under GPLv2 + exception. Is that possible to get permission from > > the FSF to borrow code from coreutils? > > If the consensus of the Fortran maintainers is that this is the right > thing to do, the SC can ask the FSF for permission. Presumably one could just take the code from the last GPLv2 version of coreutils, as well... I can't imagine /bin/chmod sees a lot of churn.
Re: use of %n in genmodes.c causes trouble on Vista
On Wed, Jun 06, 2007 at 07:29:26AM -0700, Ian Lance Taylor wrote:
> Olivier Hainque <[EMAIL PROTECTED]> writes:
>
> > genmodes.c uses the %n capabilities of printf to compute the width of
> > pieces it outputs. This causes troubles on Windows Vista, because ...
> >
> ><< Because of security reasons, support for the %n format specifier is
> > disabled by default in printf and all its variants. ... the default
> > behavior is to invoke the invalid parameter handler ...
> >>>
> >[http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx]
> >
> > It seems to me that we could replace the uses of %n by uses of printf
> > return values. I'm not clear whether this would be considered portable
> > enough, however.
>
> What is the security issue here? I'm not seeing it. Are they
> concerned that attackers will modify the print control string somehow?
There is/was a lot of code that does exactly that, a user can
manipulate the format strings (normally unintentionally, through lazy
coding). http://en.wikipedia.org/wiki/Format_string_attacks
A simple stack overflow might also allow you to write to arbitary
locations in memory. Eg:
int n = 0;
char buf[16] = { 0 };
int* n_ptr = &n;
gets(buf); // might overflow into n_ptr
printf("%s %n", buf, n_ptr);
which basically lets a remote attacker twiddle arbitrary bits in
memory. This looks contrived (and it is), but there have been attacks
against real running systems that exploited code not far off from
this.
(That said disabling %n seems pretty futile, there are many more
obvious ways to write horrible insecure code in C).
-Jack
Re: cannot pass objects of non-POD type
On Wed, Oct 24, 2007 at 12:15:03PM -0700, Andrew Pinski wrote: > > a "real" illegal instruction, caused by g++ doing something different > > that I expected with the String object as an argument? Or is the illegal > > instruction just a "place marker" that is generated because I passed > > a non-POD as an argument? > > The latter. Is there a reason it's not just an error, then? (As a user) I don't see the point of something being a warning when the compiled code is intentionally set up to crash. -Jack
Re: Optimization of conditional access to globals: thread-unsafe?
On Mon, Oct 29, 2007 at 08:37:52PM +0100, Duncan Sands wrote: > Hi Tomash, > > > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O0 mmap.c -o mmap > > moonlight:/tmp$ ./mmap > > GCC is the best compiler ever! > > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O1 mmap.c -o mmap > > moonlight:/tmp$ ./mmap > > Segmentation fault > > I don't see this with gcc 4.1 or 4.2. Just a data point. I tried this and didn't see any problems with 4.1.1 20070105 and 4.3.0 20070907 (Linux/amd64) with or without optimization (-O0, -O2, -O2 -ftree-vectorize). I thought the relevant optimization pass went in to gcc 3.4? -Jack
Re: GCC 4.3 release schedule
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote: > Create a beta that is released now and then release one once (or > twice) a month until we release 4.3. This is seperate from a release > candidate and the snapshot. The beta is get attention from some folks > that would not have used the snapshot before. It might get say some > Fortran developers or some interesting C++ developers using it. We > can write a little thing up on why we are doing the beta, C++0x > support, more fortran support and vectorizer turned on by default at > -O3. I would like this. It's common for snapshots to fail to build (at least on my machines), which is definitely a discouragement from trying them too often, and by the time the RCs hit it's way too late to do much about any problems but file a bug and hope it gets fixed in the next release. -Jack
