cording to the old ANSI standard the above construct most definitely
is a valid lvalue.
Best Regards,
Zoltan
pointer declared as void *p; as if it was a SOME_TYPE *p pointer without
introducing temporaries?
Sorry again,
Thanks,
Zoltan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Bug #: 54562
Summary: mutex and condition variable timers
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
--- Comment #1 from Zoltan Glozik
2012-09-13 02:24:24 UTC ---
Created attachment 28183
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28183
suggested patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
--- Comment #3 from Zoltan Glozik
2012-10-08 22:11:26 UTC ---
Thanks Jon, how weird to communicate with you on the gcc mailing lists...
I hope you are doing well.
Cheers,
Zoltan
> -Original Message-
> From: redi
called with an unqualified name, g1() does not find the template
function when called with a qualified name.
GCC version:
[zoltan@epcau-srv-dev:test]$ g++-4.5 -v
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/4.5/defaults.spec
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471
--- Comment #1 from Zoltan Glozik
2011-09-21 05:41:57 UTC ---
Created attachment 25330
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25330
bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471
--- Comment #2 from Zoltan Glozik
2011-09-21 05:43:44 UTC ---
Comment on attachment 25330
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25330
bug
#include
namespace NS {
template
struct A {
T t;
};
template
void f(T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50471
--- Comment #4 from Zoltan Glozik
2011-09-21 06:43:29 UTC ---
(In reply to comment #3)
> NS::f(t);
> Binds at the point at definition because it is qualified.
> f(t);
> Does not bind and then does argument dependent loo
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64
Compile the following with g++ -mcpu=power7 -S ppc_vec_extract_ice.C
This probably happens
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
Created attachment 41802
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81504
--- Comment #1 from Zoltan Hidvegi ---
This may not be a gcc-7 regression, my application fails even with gcc-6, even
with -O1 when I use vec_ld and vec_st, but works if I replace them with vec_xl
and vec_xst, and also works when I replace it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
--- Comment #2 from Zoltan Hidvegi ---
Created attachment 41855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41855&action=edit
Possible vec_insert implementation
The attached code shows two implementation for inserting a by
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Target: x86_64-*-*
__m256i foo(long x) { return (__m256i){x}; }
gcc -mavx2 -O2 generates
20: c5 f9 ef c0 vpxor %xmm0,%xmm0,%xmm0
24: c4 e3 f9
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Target: x86_64-*-*
I would like to zero out the upper 128-bit of a 256-bit vector. The Intel
intrinsics for that is _mm256_zextsi128_si256 but it&#
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at bendor dot com.au
Target Milestone: ---
Created attachment 39708
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39708&action=edit
The compiler command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #1 from Zoltan Kocsi ---
Created attachment 39709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39709&action=edit
The error message from the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #2 from Zoltan Kocsi ---
Created attachment 39710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39710&action=edit
The pre-compiled source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #4 from Zoltan Kocsi ---
Tested several gcc versions.
Up to and including 4.8.5 everything seems to be OK, but 4.9.0 or above all
throw the error.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Negating a vector variable can cause incorrect unused variable warning. This
happens both on x86 and PowerPC. Compile with g++ -O2 -S -Wall warning_test.C
Interestingly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78246
--- Comment #1 from Zoltan Hidvegi ---
Created attachment 39986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39986&action=edit
gcc -O2 -S -Wall warning_test.C gives incorrect warning: variable ‘sm’ set but
not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
Zoltan Hidvegi changed:
What|Removed |Added
CC||zoltan at hidvegi dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
--- Comment #5 from Zoltan Hidvegi ---
Btw. the original testcase was really failing because of Bug 33704, and it
seems that is already fixed, however it's still open, or is it not fully fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #6 from Zoltan Hidvegi ---
gcc collect2 links the programs twice, first it links just all the object and
archive files passed, then it parses the output and if necessary creates a
source file that contains information about static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #8 from Zoltan Hidvegi ---
How about using -bkeepfile: for all linked .o objects, that would create a very
similar semantics to other platforms, all .o objects are included, and only
objects that resolve undefined symbols would be
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
typedef signed char v16si __attribute__ ((vector_size (16)));
v16si ary(signed char a)
{
return v16si{a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
}
Compiled with g++-4.9 -m64 -O2 -fomit-frame-pointer -Wall -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
Zoltan Hidvegi changed:
What|Removed |Added
CC||zoltan at hidvegi dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #6 from Zoltan Hidvegi ---
Created attachment 34672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34672&action=edit
Patch to limit dbx stabstring length to 32000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #7 from Zoltan Hidvegi ---
With the above trivial change I've been able to build code with long
stabstrings on AIX 6.1. I was using the gcc-4.8 branch since that's what we are
using here. If you fix this, could you please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #9 from Zoltan Hidvegi ---
xlC generates stubs with continuation, and it seems to cut them at 16k both for
32-bit and 64-bit objects, so maybe gcc could do the same. gdb-7.7.1 seems to
segfault on stubs longer than 32k for 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #11 from Zoltan Hidvegi ---
Do you have more info regarding the AIX assembler bug you are referring to?
PR46072 was about a different assembler bug, it's just someone in that report
have also encountered the stabstring length
If a file has errors and gcc gets the -V X.X.X command line option, then the
exit code is 0. The following illustrates it:
[zoltan manocska]~>arm-elf-gcc --version
arm-elf-gcc (GCC) 4.4.0
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copy
constants cost more than the calculations
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zoltan at bendor dot com dot
--- Comment #1 from zoltan at bendor dot com dot au 2009-03-15 22:51
---
Created an attachment (id=17467)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17467&action=view)
Demonstrates the constant loading cost problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
--- Comment #4 from zoltan at bendor dot com dot au 2009-03-15 23:21
---
Subject: Re: Constant propagation in a number
of tree passes does not take into account machine costs.
I have also filed a bug report, 39469, with a much simpler and clearer
test code. Maybe the two should be
lr
instruction.
--
Summary: Very inefficient code generated
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zolt
crash
the AVR
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zoltan at bendor dot com dot au
--- Additional Comments From zoltan at bendor dot com dot au 2005-09-26
07:42 ---
Subject: A gcc primitive, under special circumstances, can crash the AVR
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-23
> 12:56 ---
> Is there
--- Additional Comments From zoltan at bendor dot com dot au 2005-09-27
11:30 ---
Subject: A gcc primitive, under special circumstances, can crash the AVR
Additional comment:
The bug can be retired. Atmel confirmed (and the latest AT90CAN128
manual lists it in the errata) that the
nhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zoltan at bendor dot com dot au
GCC host triplet: i586-gnu-linux
GCC target triplet: arm-elf-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43003
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zoltan at bendor dot com dot au
GCC build triplet: x86-elf-linux
--- Comment #1 from zoltan at bendor dot com dot au 2008-07-15 22:33
---
Created an attachment (id=15915)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15915&action=view)
Test code to demonstrate the size increase
A short C file that compiles to about 60% larger with
: zoltan at bendor dot com dot au
GCC build triplet: x86-linux-elf
GCC host triplet: x86-linux-elf
GCC target triplet: avr-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36845
download of gcc-4.1.0. Then:
~/GNU/gcc-mcore> ../gcc-4.1.0/configure --target=mcore-elf --with-gnu-as
--with-gnu-ld --enable-languages=c
Configure succeeds, typing make successfully builds xgcc.
It starts to build the libraries, and it fails:
/home/zoltan/GNU/gcc-mcore/./gcc/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117729
Zoltan Hidvegi changed:
What|Removed |Added
CC||zoltan at hidvegi dot com
--- Comment
45 matches
Mail list logo
