Hi,
attached is a revised and extended patch. Changes with respect
to the previous patch are:
- warn if qualifiers are lost for pointers to multi-dimensional arrays
- warn if qualifiers are lost when converting to void*
- warnings for _Atomic are preserved
- qualifiers are not lost in condit
On 28 October 2014 19:36, Toon Moene wrote:
> On the gcc-results archive, you'll see this:
>
> https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02983.html
>
> but that doesn't show you the real problem:
>
> mkdir -p -- /home/toon/compilers/install/share/gcc-5.0.0/python/libjava
> libtool: install:
On the gcc-results archive, you'll see this:
https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02983.html
but that doesn't show you the real problem:
mkdir -p -- /home/toon/compilers/install/share/gcc-5.0.0/python/libjava
libtool: install: /usr/bin/install -c .libs/libgcj-tools.so.15.0.0T
/hom
On Tue, Oct 28, 2014 at 3:45 PM, Rogelio Serrano
wrote:
> any hint debugging this?
>
> /home/rogelio/gcc-build/./prev-gcc/g++
> -B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/
> -nostdinc++
> -B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
> -
While doing some benchmark flag mining on AArch64, I noticed that
-fpeel-loops was a mined option often. As a matter of fact, when using it
always, even without FDO, it seemed to raise most benchmarks and to leave
almost all of the rest flat, with a barely noticeable cost in code-size. It
seems t
any hint debugging this?
/home/rogelio/gcc-build/./prev-gcc/g++
-B/home/rogelio/gcc-build/./prev-gcc/ -B/x86_64-unknown-linux-gnu/bin/
-nostdinc++
-B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/rogelio/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/li
On 10/28/14 06:40, Jakub Jelinek wrote:
I'd say if on the target reg26 or reg27 is used or clobbered by
multiplication, then it is a user error to use it this way, the register
then isn't suitable for the local hard register usage.
Right.
And this situation is a great example of why clobbering
On Tue, Oct 28, 2014 at 01:06:38PM +0100, Georg-Johann Lay wrote:
> The C test case is
>
>
> __attribute__((noinline,noclone))
> unsigned bug_mulhi_highpart (unsigned x)
> {
> register unsigned reg26 asm ("26") = 10;
> a = x / 10;
> __asm volatile ("; %0 " : "+r" (reg26));
> retur
Am 10/27/2014 08:43 PM, schrieb Jeff Law:
On 10/27/14 13:33, Georg-Johann Lay wrote:
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit
tedious,
but well...
In one
On 28 October 2014 09:33, Alex Markin wrote:
> Hello, everyone.
>
> I have a question about "One definition rule" for classes in different
> translation units and gcc behaviour. Let us have the following
> program:
Your question is off topic on this mailing list, which is for
discussing developmen
Hello, everyone.
I have a question about "One definition rule" for classes in different
translation units and gcc behaviour. Let us have the following
program:
//-- t1.cpp
#include
#include
class A
{
public:
A(){printf("1\n");a=1;}
int a;
};
void foo(void * a)
{
a = new A;
}
11 matches
Mail list logo
