ICE in 4.8.2 with compound literal
Hello,
This ICE may have gotten lost in the noise of my own message.
https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
(The code snippet might be invalid C)
$ gcc -std=gnu99 -O3 -S test.c
test.c: In function 'main':
test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
int main() { return *(adds[0]); }
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
your bugreport.
// /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -imultiarch x86_64-linux-gnu
test.c -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -O3
-std=gnu99 -o - -fstack-protector -Wformat -Wformat-security -frandom-seed=0
# 1 "test.c"
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.c"
union foo { struct { unsigned baz: 3, bar: 1; } bits; int value; };
int * const adds[] = {&(((union foo){.bits={ .bar = 0x1 }}).value)};
int main() { return *(adds[0]); }
Regards.
Re: ICE in 4.8.2 with compound literal
On Tue, Nov 25, 2014 at 09:30:05AM +0100, Mason wrote:
> Hello,
>
> This ICE may have gotten lost in the noise of my own message.
> https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
>
> (The code snippet might be invalid C)
>
> $ gcc -std=gnu99 -O3 -S test.c
> test.c: In function 'main':
> test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
> int main() { return *(adds[0]); }
> ^
I can reproduce the error. Please do...
> Please submit a full bug report,
this, and don't forget about:
> with preprocessed source if appropriate.
> See for instructions.
> Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
> your bugreport.
(If you need to create a BZ account, please mail overseers and I'll
take care of that.)
Thanks,
Marek
Re: ICE in 4.8.2 with compound literal
Hello Marek,
On 25/11/2014 09:47, Marek Polacek wrote:
On Tue, Nov 25, 2014 at 09:30:05AM +0100, Mason wrote:
This ICE may have gotten lost in the noise of my own message.
https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
(The code snippet might be invalid C)
$ gcc -std=gnu99 -O3 -S test.c
test.c: In function 'main':
test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
int main() { return *(adds[0]); }
^
I can reproduce the error. Please do...
Please submit a full bug report,
OK, I'm trying to read between the lines here. You want a *full* bug report,
that means you consider the initial report to be incomplete?
Seems I omitted the output of "gcc -v"
Was there other stuff missing?
I'll be sure to read https://gcc.gnu.org/bugs/ more closely.
this, and don't forget about:
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to
your bugreport.
I'm confused, because I did provide that part in the initial report.
(If you need to create a BZ account, please mail overseers and I'll
take care of that.)
Aaah, you want me to post the bug report to BZ, not here...
OK, I can do that. I've successfully created an account.
When you have a minute, can you take a look at my other message?
"Using Compound Literal + type-punning to initialize static const array"
You committed a patch that seems relevant just a few days ago. But the
documentation lead me to believe that the feature I was looking for had
been supported for a very long time (gcc 3.x at least)
Regards.
Re: ICE in 4.8.2 with compound literal
On Tue, Nov 25, 2014 at 10:19:21AM +0100, Mason wrote: > Aaah, you want me to post the bug report to BZ, not here... Yep - the snippet + command-line options you posted was enough to reproduce the bug. The GCC mailing list is not for reporting bugs. > When you have a minute, can you take a look at my other message? > "Using Compound Literal + type-punning to initialize static const array" > > You committed a patch that seems relevant just a few days ago. But the > documentation lead me to believe that the feature I was looking for had > been supported for a very long time (gcc 3.x at least) I haven't read that in detail yet, but my patch just allowed the initializing even for gnu99/gnu11 (formerly, it was only allowed in the gnu89 mode). Marek
Re: ICE in 4.8.2 with compound literal
On 25/11/2014 10:27, Marek Polacek wrote:
On Tue, Nov 25, 2014 at 10:19:21AM +0100, Mason wrote:
Aaah, you want me to post the bug report to BZ, not here...
Yep - the snippet + command-line options you posted was enough to reproduce
the bug. The GCC mailing list is not for reporting bugs.
Gotcha.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64067
When you have a minute, can you take a look at my other message?
"Using Compound Literal + type-punning to initialize static const array"
You committed a patch that seems relevant just a few days ago. But the
documentation lead me to believe that the feature I was looking for had
been supported for a very long time (gcc 3.x at least)
I haven't read that in detail yet, but my patch just allowed the
initializing even for gnu99/gnu11 (formerly, it was only allowed in the
gnu89 mode).
Hmmm, then my test case incorrectly used gnu99.
Here's a simpler test case, using gnu89, producing the same error:
union foob { int val; struct { int X; } bits; };
static const int u = ((union foob) {.bits = { .X=42 }}).val;
$ gcc -std=gnu89 test.c
test.c:2:30: error: initializer element is not constant
static const int u = ((union foob) {.bits = { .X=42 }}).val;
Isn't this supposed to work? Or did I misunderstand the extension?
(Tell me if I should file a bug report.)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-3
2
=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Regards.
Re: Missing git tags for released GCC
On 16 November 2014 at 15:51, H.J. Lu wrote: > Hi, > > Git tags are missing for GCC 4.9.1, 4.9.2, 4.8.3 and 4.7.4. I can't create the tags but these are the release commits: git tag gcc-4_9_2-release c1283af40b65f1ad862cf5b27e2d9ed10b2076b6 git tag gcc-4_9_1-release c6fa1b412663593960e6240eb66d82fa41a1fa0b git tag gcc-4_8_3-release 6bbf0dec66c0e719b06cd2fe67559fda6df09000 git tag gcc-4_7_4-release ae10eb82fe34c18640ad65c2ab94ffc53f349315
Re: [PATCH] gcc parallel make check
On 15-09-14 18:05, Jakub Jelinek wrote:
libstdc++-v3/
* testsuite/Makefile.am (check_p_numbers0, check_p_numbers1,
check_p_numbers2, check_p_numbers3, check_p_numbers4,
check_p_numbers5, check_p_numbers6, check_p_numbers,
check_p_subdirs): New variables.
(check_DEJAGNU_normal_targets): Use check_p_subdirs.
(check-DEJAGNU): Rewritten so that for parallelized
testing each job runs all the *.exp files, with
GCC_RUNTEST_PARALLELIZE_DIR set in environment.
* testsuite/Makefile.in: Regenerated.
* testsuite/lib/libstdc++.exp (gcc_parallel_test_run_p,
gcc_parallel_test_enable): New procedures. If
GCC_RUNTEST_PARALLELIZE_DIR is set in environment, override
runtest_file_p to invoke also gcc_parallel_test_run_p.
* testsuite/libstdc++-abi/abi.exp: Run all the tests serially
by the first parallel runtest encountering it. Fix up path
of the extract_symvers script.
* testsuite/libstdc++-xmethods/xmethods.exp: Run all the tests
serially by the first parallel runtest encountering it. Run
dg-finish even in case of error.
When comparing test results of patch builds with test results of reference
builds, the only differences I'm seeing are random differences in amount of
'UNSUPPORTED: prettyprinter.exp'.
This patch fixes that by ensuring that we print that unsupported message only
once.
The resulting test result comparison diff is:
...
--- without/FAIL 2014-11-24 17:46:32.202673282 +0100
+++ with/FAIL 2014-11-25 13:45:15.636131571 +0100
libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: prettyprinters.exp
-libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: prettyprinters.exp
-libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: prettyprinters.exp
-libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: prettyprinters.exp
-libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: prettyprinters.exp
libstdc++-v3/testsuite/libstdc++.sum:UNSUPPORTED: xmethods.exp
...
Furthermore, the patch adds a dg-finish in case the prettyprinters.exp file is
unsupported, which AFAIU is also required in that case.
Bootstrapped and reg-tested on x86_64.
OK for trunk/stage3?
Thanks,
- Tom
2014-11-25 Tom de Vries
* testsuite/libstdc++-prettyprinters/prettyprinters.exp: Add missing
dg-finish. Only print unsupported message once.
---
libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
index a57660f..e5be5b5 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
@@ -30,7 +30,14 @@ if ![info exists ::env(GUALITY_GDB_NAME)] {
}
if {! [gdb_version_check]} {
+dg-finish
+# Only print unsupported message in one instance.
+if ![gcc_parallel_test_run_p prettyprinters] {
+ return
+}
+gcc_parallel_test_enable 0
unsupported "prettyprinters.exp"
+gcc_parallel_test_enable 1
return
}
--
1.9.1
optab handler for floating point to interger "fix" is not generated
Hi, I'm still a newbie to gcc porting and ask you for help. I'm porting gcc to generate added hardware FPU unit to an existing architecture (tile64). Without the hardware FPU unit, soft-float is used to handle floating point operations. Now, arithmetic instructions using FPU is properly generated, but "fix/trunc" and logical operations for floating point types are not handled, yet. I've put something like the following code in the machine description file, but the proper optab handlers for the fix instructions are not generated. As a result, soft-float routines are called instead. (define_expand "fix_sfsi2" [(set (match_operand:SI 0 "register_operand" ) (fix:SI (match_operand:SF 1 "register_operand" ) ))] I checked that there are no explicit 'set_conv_libfunc' calls in the code. Could someone tell me what I am doing wrong? And I'll appreciate what architecture is similar and helpful for me to port gcc with the newly added FPU. Thanks, David -- -- Dr. Dong-In "David" Kang Computer Scientist USC/ISI
Re: optab handler for floating point to interger "fix" is not generated
On Tue, Nov 25, 2014 at 08:18:39AM -0800, David Kang wrote: > (define_expand "fix_sfsi2" The proper name is "fixsfsi2", no underscore. You might want "fix_truncsfsi2" instead though. Segher
Re: optab handler for floating point to interger "fix" is not generated
Thank you very much. It solves my problem. Now optab for the conversion is generated properly. Is the logical operators described similarly? I tried "seqf2", "cmpseqf2", and "one_cmplseqf2" for "eq" of two floating point numbers as it is shown below. But none of them work. (define_expand "seqf2" [(set (match_operand:SI 0 "register_operand" "") (eq:SI (match_operand:SF 1 "register_operand" "") (match_operand:SF 2 "register_operand" "")))] Thank you, David - Original Message - > From: "Segher Boessenkool" > To: "David Kang" > Cc: "GCC" > Sent: Tuesday, November 25, 2014 1:21:38 PM > Subject: Re: optab handler for floating point to interger "fix" is not > generated > On Tue, Nov 25, 2014 at 08:18:39AM -0800, David Kang wrote: > > (define_expand "fix_sfsi2" > > The proper name is "fixsfsi2", no underscore. You might want > "fix_truncsfsi2" instead though. > > > Segher -- -- Dr. Dong-In "David" Kang Computer Scientist USC/ISI
Re: [PATCH] gcc parallel make check
On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
> This patch fixes that by ensuring that we print that unsupported message only
> once.
>
> The resulting test result comparison diff is:
> 2014-11-25 Tom de Vries
>
> * testsuite/libstdc++-prettyprinters/prettyprinters.exp: Add missing
> dg-finish. Only print unsupported message once.
LGTM.
> --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
> +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
> @@ -30,7 +30,14 @@ if ![info exists ::env(GUALITY_GDB_NAME)] {
> }
>
> if {! [gdb_version_check]} {
> +dg-finish
> +# Only print unsupported message in one instance.
> +if ![gcc_parallel_test_run_p prettyprinters] {
> + return
> +}
> +gcc_parallel_test_enable 0
> unsupported "prettyprinters.exp"
> +gcc_parallel_test_enable 1
> return
> }
>
> --
> 1.9.1
>
Jakub
Re: optab handler for floating point to interger "fix" is not generated
On Tue, Nov 25, 2014 at 10:45:06AM -0800, David Kang wrote: > Is the logical operators described similarly? > I tried "seqf2", "cmpseqf2", and "one_cmplseqf2" for "eq" of two floating > point numbers as it is shown below. > But none of them work. > > (define_expand "seqf2" > [(set (match_operand:SI 0 "register_operand" "") > (eq:SI (match_operand:SF 1 "register_operand" "") > (match_operand:SF 2 "register_operand" "")))] This is done via cstoresf4. Please see the `gccint' manual, available online or via e.g. `make pdf'; or read gcc/doc/md.texi directly. Segher
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On Nov 23, 2014, at 4:06 PM, FX wrote: > One question to build maintainers, and one patch submitted to top-level > configure.ac So, not sure who wants to review this. From the darwin perspective, Ok.
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On 25/11/14 20:37, Mike Stump wrote: > On Nov 23, 2014, at 4:06 PM, FX wrote: >> One question to build maintainers, and one patch submitted to top-level >> configure.ac > > So, not sure who wants to review this. From the darwin perspective, Ok. I mean from my limited viewpoint it looks fine. As long as the .so is built, that's really our only goal from a GDB point of view. But I am not a maintainer, so I have refrained from commenting on this change, as it seems fairly straightforward. Though I am no expert on GCC build systems. Cheers Phil
Re: optab handler for floating point to interger "fix" is not generated
Thanks a lot. As a newbie, I keep reading the gccint manual and the source code. But, the document is not kind enough for a newbie to jump start in a short amount of time. Sometimes an advice from an expert gives a newbie a breakthrough. I appreciate your help! David - Original Message - > From: "Segher Boessenkool" > To: "David Kang" > Cc: "GCC" > Sent: Tuesday, November 25, 2014 3:25:47 PM > Subject: Re: optab handler for floating point to interger "fix" is not > generated > On Tue, Nov 25, 2014 at 10:45:06AM -0800, David Kang wrote: > > Is the logical operators described similarly? > > I tried "seqf2", "cmpseqf2", and "one_cmplseqf2" for "eq" of two > > floating point numbers as it is shown below. > > But none of them work. > > > > (define_expand "seqf2" > > [(set (match_operand:SI 0 "register_operand" "") > > (eq:SI (match_operand:SF 1 "register_operand" "") > > (match_operand:SF 2 "register_operand" "")))] > > This is done via cstoresf4. Please see the `gccint' manual, available > online or via e.g. `make pdf'; or read gcc/doc/md.texi directly. > > > Segher -- -- Dr. Dong-In "David" Kang Computer Scientist USC/ISI
Re: Optimized Allocation of Argument registers
On 11/24/2014 06:47 AM, Ajit Kumar Agarwal wrote: > All: > > The optimization of reducing save and restore of the callee and caller saved > register has been the attention Of > increasing the performance of the benchmark. The callee saved registers is > saved at the entry and restore at the > exit of the procedure if the register is reused inside the procedure whereas > the caller save registers at the Caller site > is saved before the call and the restore after the variable is live and spans > through the call. > > The GCC port has done some optimization whereas the call-used registers are > live inside the procedure and has been > set as 1 bit then it will not be saved and restored. This is based on the > data flow analysis. > > The callee saved registers is useful when there all multiple calls in the > call graph whereas the caller save registers are > useful if the call is the leaf procedure then the saving before the call and > restore after the call will be useful and increases > the performance. > > By traversing the call graph in depth-first-order and the bottom-up approach > we can propagate the save and restore > At the procedure entry and exit to the upper regions of the call graph which > reduces the save and restore at all the lower > Regions across the various lower calls. These decision can be made based on > the frequency of the call in the call graph as > Proposed by Fred Chow. > It is hard to implement as you need to change already generated code (in callees or callers depending in what order you are generating code for functions in the call graph). You can not decide what you will do without RA at least in one function (caller or callee). Although some rough heuristics are possible on existing call graph level but I guess they will probably hurt more than improve the code because the estimation will be very inaccurate. Although if you create an infrastructure to do such things (having RTLs of all functions compiled). It could be useful for other projects too, e.g. for Minimum Cost Interprocedural Register Allocation (see http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.5914) which is more general approach to what you propose.
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
On 11/25/14 13:57, Phil Muldoon wrote: On 25/11/14 20:37, Mike Stump wrote: On Nov 23, 2014, at 4:06 PM, FX wrote: One question to build maintainers, and one patch submitted to top-level configure.ac So, not sure who wants to review this. From the darwin perspective, Ok. I mean from my limited viewpoint it looks fine. As long as the .so is built, that's really our only goal from a GDB point of view. But I am not a maintainer, so I have refrained from commenting on this change, as it seems fairly straightforward. Though I am no expert on GCC build systems. I'm not sure there *is* an expert on the GCC buildsystem :( jeff
Re: [PATCH] gcc parallel make check
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek wrote: > On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote: >> This patch fixes that by ensuring that we print that unsupported message >> only once. >> >> The resulting test result comparison diff is: >> 2014-11-25 Tom de Vries >> >>* testsuite/libstdc++-prettyprinters/prettyprinters.exp: Add missing >>dg-finish. Only print unsupported message once. > > LGTM. That is the approval. :-)
