tested following code with
http://gcc.godbolt.org/
tested with
g++-4.8 (Ubuntu 4.8.1.2ubuntu1~12.04) 4.8.1
g++ (GCC) 4.9.0 20130909 (experimental)
and the result with -O3 + defined USE_ITER seems to be a little bit long
--
static void foo(int a, int& dummy)
{
dummy += a;
}
#define U
On 18/07/14 08:30, Dennis Luehring wrote:
>int* array = (int*)&argv;
This looks like undefined behaviour. Don't you get a warning?
Andrew.
Am 18.07.2014 10:29, schrieb Andrew Haley:
On 18/07/14 08:30, Dennis Luehring wrote:
>int* array = (int*)&argv;
This looks like undefined behaviour. Don't you get a warning?
Andrew.
no warning - its an valid typed pointer to stack and i don't care what
the values are
its just an anti-
On 07/18/2014 09:40 AM, Dennis Luehring wrote:
> Am 18.07.2014 10:29, schrieb Andrew Haley:
>> On 18/07/14 08:30, Dennis Luehring wrote:
>>>int* array = (int*)&argv;
>>
>> This looks like undefined behaviour. Don't you get a warning?
>
> no warning - its an valid typed pointer to stack and i
Am 18.07.2014 11:14, schrieb Andrew Haley:
On 07/18/2014 09:40 AM, Dennis Luehring wrote:
> Am 18.07.2014 10:29, schrieb Andrew Haley:
>> On 18/07/14 08:30, Dennis Luehring wrote:
>>>int* array = (int*)&argv;
>>
>> This looks like undefined behaviour. Don't you get a warning?
>
> no warning
Hi,
On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
> I've recently discovered that a function marked always_inline but
> called by pointer won't always be inlined. What would it take to
> assure that this either always happens or generates an error?
Generally, that is the case. D
On 07/08/14 14:21, David Malcolm wrote:
[CCing nickc, who wrote the mn10300 hook in question]
I'm experimenting with separating out instructions from expressions in
RTL; see [1] for more info on that.
I noticed that mn10300 has this implementation of a target hook:
#define TARGET_SCHED_ADJUS
On 07/18/2014 04:55 AM, Martin Jambor wrote:
Hi,
On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
I've recently discovered that a function marked always_inline but
called by pointer won't always be inlined. What would it take to
assure that this either always happens or generates
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
msys2 x86_64-w64-mingw32 setup on windows 7 system with an Intel(R) Xeon(R) E5
1660 v2 cpu, see http://sourceforge.net/p/mingw-w64/mailman/message/32493707/
mingw-w64 is trunk as of 21st of May.
testsuite results see
https://gcc.gnu.org/ml/gcc-testres
On 07/18/2014 04:55 AM, Martin Jambor wrote:
Hi,
On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
I've recently discovered that a function marked always_inline but
called by pointer won't always be inlined. What would it take to
assure that this either always happens or generates
See bug entry for more details: b.android.com/73728
On Thu, Jul 17, 2014 at 8:39 AM, Andrew Hsieh wrote:
> Bionic headers prior to android-L (for L-preview) aren't changed
> except for bug fixes since last major update in android-9 (gingerbread
> era), the API level used to build all 32-bit NDK t
11 matches
Mail list logo