[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #51 from GoWhoopee at yahoo dot com --- http://web.cs.dal.ca/~vlado/pl/C_Standard_2011-n1570.pdf That's the principle, but not what happens with gcc... Phase 2 says, "Each instance of a backslash character (\) immediately followed by a newline character is deleted, splicing physical source lines to form logical source lines.", and explicitly states that, "Only the last backslash on any physical source line shall be eligible for such a splice.". I wonder if all trailing white-space is being trimmed from each source line before or during the first Translation Phase?
[Bug fortran/59450] [OOP] ICE for type-bound-procedure expression in module procedure interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450 --- Comment #5 from b...@miller-mohr.de --- (In reply to janus from comment #4) > (In reply to janus from comment #2) > > Draft patch which fixes the error (not regtested): > > Does regtest cleanly. Hi, just wanted to say thanks. Your speed is terrific :) Cheers Marcus
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
--- Comment #10 from Rainer Emrich ---
Am 12.12.2013 23:08, schrieb ktietz at gcc dot gnu.org:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897
>
> --- Comment #9 from Kai Tietz --- By following
> patch for me the issue is solved:
>
> Index: i386.c
> === ---
> i386.c (Revision 205859) +++ i386.c (Arbeitskopie) @@ -3698,6
> +3698,10 @@ { if (opts->x_optimize >= 1 &&
> !opts_set->x_flag_omit_frame_pointer) opts->x_flag_omit_frame_pointer =
> !USE_X86_64_FRAME_POINTER; + if
> (opts->x_flag_asynchronous_unwind_tables + &&
> !opts_set->x_flag_unwind_tables + && TARGET_64BIT_MS_ABI) +
> opts->x_flag_unwind_tables = 1; if (opts->x_flag_asynchronous_unwind_tables
> == 2) opts->x_flag_unwind_tables = opts->x_flag_asynchronous_unwind_tables
> = 1;
>
> I will apply this patch to trunk soon, if there are no objections.
>
I confirm, this solves the issue!
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 Ever confirmed|0 |1 --- Comment #12 from Eric Botcazou --- I can reproduce on the ARM, it was introduced by r205461.
[Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #13 from Eric Botcazou --- Looking into it.
[Bug tree-optimization/34723] Summing variable should be initialized to the first member before the loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34723 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #0) > Note that gcc-4.3 initializes summation variable to zero, where gcc-4.2 > initializes summation variable to first array member, saving one loop > iteration. Reconfirmed on 4.9. I'm adding Jeff to CC for his opinon on Andrew's "jump threading used to mess up the loop" observation from comment #1.
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #11 from Kai Tietz --- Author: ktietz Date: Fri Dec 13 09:24:16 2013 New Revision: 205957 URL: http://gcc.gnu.org/viewcvs?rev=205957&root=gcc&view=rev Log: PR c++/57897 * config/i386/i386.c (ix86_option_override_internal): Set for x64 target flag_unwind_tables, if flag_asynchronous_unwind_tables was explicit set. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Kai Tietz --- Fixed
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 Richard Biener changed: What|Removed |Added Version|unknown |4.9.0 Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener --- r202826 was fixed later by the fix for PR58656 (rnflow regression), so your bisection converged on a bogus revision.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 Tobias Burnus changed: What|Removed |Added Depends on||58721 --- Comment #2 from Tobias Burnus --- If the draft/RFC patch for PR58721 fixes the issue then mark this PR depend on the other one. Additionally, the cause is then presumably the same - namely the tuning of the builtin-expect probability in commit r203167; the change itself is okay even if it clashes with gfortran's internal use - but that can be fixed differently as discussed in the draft patch plus the other PR.
[Bug libstdc++/59436] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Uroš Bizjak changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-12-13 Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak --- These failures are still present on i686-pc-linux-gnu [1], rev 205955: Running target unix FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) [1] http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01213.html
[Bug c/59491] New: compiler can't detect if xpression is always fixed value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59491
Bug ID: 59491
Summary: compiler can't detect if xpression is always fixed
value
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Given the following code
void g( int n);
void f( int n)
{
if ((n & 0x08) == 1)
g( n);
}
trunk gcc says not a lot
[dcb@zippy4 Alphasrc]$ ~/gcc/results/bin/gcc -g -O2 -Wall -c dec12b.cc
[dcb@zippy4 Alphasrc]$ ~/gcc/results/bin/gcc -g -O2 -Wall -Wextra -pedantic -c
dec12b.cc
Here is cppcheck being a bit more vocal about it
[dcb@zippy4 Alphasrc]$ cppcheck --enable=all dec12b.cc
Checking dec12b.cc...
[dec12b.cc:6]: (style) Expression '(X & 0x8) == 0x1' is always false.
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 --- Comment #4 from Janne Blomqvist --- Indeed I suspect we have many cases in the IO library where stuff fails, leaks memory, or leaves stuff in an inconsistent state when IOSTAT= is present. I think that we should modify generate_error() to not terminate the program in case IOSTAT= is not present, but instead we return and unwind the IO call stack (manually with return statements since this is plain old C), and then only at the end just before we return to the user Fortran program we check IOPARM_HAS_IOSTAT and IOPARM_LIBRETURN_MASK and exit() if appropriate. That way error handling works the same whether IOSTAT= is present or not. But such a change is probably 4.10 material.
[Bug middle-end/39838] [4.7/4.8/4.9 regression] unoptimal code for two simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #15 from bin.cheng ---
The situation gets a little bit better on 4_9 trunk. The Os assembly code on
cortex-m0 (thumb1 as reported) is like:
test:
push{r0, r1, r2, r4, r5, r6, r7, lr}
movr6, r0
movr4, #0
strr2, [sp, #4]
.L2:
ldrr2, [r6]
cmpr4, r2
bge.L7
movr5, #0
lslr7, r4, #2
addr2, r7, #4
[Bug target/59492] New: [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 Bug ID: 59492 Summary: [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org bootstrap failure on x32 when configured with --enable-libstdcxx-debug, using binutils 2.24. libtool: compile: /scratch/packages/gcc/snap/gcc-snapshot-20131213/build/./gcc/xgcc -shared-libgcc -B/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/./gcc -nostdinc++ -L/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/src -L/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/src/.libs -L/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/libsupc++/.libs -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/x86_64-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/x86_64-linux-gnu/include -isystem /usr/lib/gcc-snapshot/x86_64-linux-gnu/sys-include -mx32 -I/scratch/packages/gcc/snap/gcc-snapshot-20131213/src/libstdc++-v3/../libgcc -I/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/include/x86_64-linux-gnux32 -I/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/include -I/scratch/packages/gcc/snap/gcc-snapshot-20131213/src/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=random.lo -gdwarf-4 -g3 -O0 -c ../../../../../../../src/libstdc++-v3/src/c++11/random.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o random.o /tmp/ccZaxDk3.s: Assembler messages: /tmp/ccZaxDk3.s: Error: cannot represent relocation type BFD_RELOC_64_PCREL in x32 mode /tmp/ccZaxDk3.s: Error: cannot represent relocation type BFD_RELOC_64_PCREL in x32 mode make[14]: *** [random.lo] Error 1 make[14]: Leaving directory `/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/src/debug/c++11' make[14]: Entering directory `/scratch/packages/gcc/snap/gcc-snapshot-20131213/build/x86_64-linux-gnu/x32/libstdc++-v3/src/debug' make[14]: *** No rule to make target `../../src/debug/c++11/libc++11convenience.la', needed by `libstdc++.la'. Stop.
[Bug preprocessor/8270] [4.7/4.8/4.9 Regression] back-slash white space newline with comments, no warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
--- Comment #52 from GoWhoopee at yahoo dot com ---
Whitespace is required by Translation Phase 3, consequently Translation Phase 1
should not be changing whitespace at all, only mapping multibyte characters and
trigraphs.
Comment #39: Indicates that gcc is known to work incorrectly, "This (removal of
such spaces) is part of how GCC defines the implementation-defined mapping in
translation phase 1.": the removal of white-space is not mapping multibyte
characters or trigraphs, it is removing critical information from Translation
Phases 2 and 3 resulting in misinterpretation of the source code.
Looking at the 4.8.2 source, libcpp\lex.c line 1427, there is a fix when
parsing raw strings, after the event:
__
static void
lex_raw_string (cpp_reader *pfile, cpp_token *token, const uchar *base,
const uchar *cur)
{
[...]
switch (note->type)
{
case '\\':
case ' ':
/* Restore backslash followed by newline. */
BUF_APPEND (base, cur - base);
base = cur;
BUF_APPEND ("\\", 1);
after_backslash:
if (note->type == ' ')
{
/* GNU backslash whitespace newline extension. FIXME
could be any sequence of non-vertical space. When we
can properly restore any such sequence, we should mark
this note as handled so _cpp_process_line_notes
doesn't warn. */
BUF_APPEND (" ", 1);
}
BUF_APPEND ("\n", 1);
break;
__
but fixing all the varieties of broken things after the event wouldn't be
necessary if Translation Phase 1 didn't trim whitespace.
If Translation Phase 1 is required to trim whitespace for some reason
(performance, perhaps) then it should trim multiple consecutive spaces down to
exactly one space; which wouldn't break Translation Phase 2 and 3.
Does that sound like a sensible compromise?
[Bug middle-end/59471] [4.9 Regression] ICE using vector extensions (non-top-level BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 Component|tree-optimization |middle-end Version|unknown |4.9.0 Target Milestone|--- |4.9.0 Summary|ICE using vector extensions |[4.9 Regression] ICE using |(non-top-level |vector extensions |BIT_FIELD_REF, |(non-top-level |IMAGPART_EXPR or|BIT_FIELD_REF, |REALPART_EXPR) |IMAGPART_EXPR or ||REALPART_EXPR) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug ipa/59473] [4.9 Regression] ice in get_class_context with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59473 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Component|c++ |ipa Target Milestone|--- |4.9.0 Summary|ice in get_class_context|[4.9 Regression] ice in |with -O3|get_class_context with -O3
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 Richard Biener changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org Component|lto |ipa Target Milestone|--- |4.9.0 Summary|LLVM build failure with gcc |[4.8/4.9 Regression] LLVM |LTO |build failure with gcc LTO
[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477 Richard Biener changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Target Milestone|--- |4.8.3
[Bug tree-optimization/59479] Inlining of static function bloats code size when Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59479 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think you likely see a 2nd-order effect. Inlining a once called function should not increase code size. But of course optimization opportunities exposed by it may trigger optimizers that are not well tuned to honor -Os. So, can you narrow down the issue a bit?
[Bug middle-end/39838] [4.7/4.8/4.9 regression] unoptimal code for two simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 --- Comment #16 from bin.cheng --- For optimization level O2, the dump before IVOPT is like: : _21 = p_6(D)->count; if (_21 > 0) goto ; else goto ; : : # i_26 = PHI if (count_8(D) > 0) goto ; else goto ; : pretmp_23 = (sizetype) i_26; pretmp_32 = pretmp_23 + 1; pretmp_33 = pretmp_32 * 4; pretmp_34 = pretmp_23 * 4; : # j_27 = PHI _9 = p_6(D)->data; _13 = _9 + pretmp_33; _14 = *_13; _16 = _9 + pretmp_34; _17 = *_16; func (_17, _14); j_19 = j_27 + 1; if (count_8(D) > j_19) goto ; else goto ; : goto ; : : i_20 = i_26 + 1; _7 = p_6(D)->count; if (_7 > i_20) goto ; else goto ; : goto ; : return; There might be two issues that block IVOPT choosing the biv(i) for pretmp_33 and pretmp_34: 1) on some target (like ARM), "i << 2 + 4" can be done in one instruction, if the cost is same as simple shift or plus, then overall cost of biv(i) is lower than the two candidate iv sets. GCC doesn't do such check in get_computation_cost_at for now. 2) there is CSE opportunity between computation of pretmp_33 and pretmp_34, for example they can be computed as below: pretmp_33 = i << 2 pretmp_34 = pretmp_33 + 4 but GCC IVOPT is insensitive to such CSE opportunities between different iv uses. I guess this isn't easy because unless the two uses are very close in code (like this one), such CSE may avail to nothing. These kind tweaks on cost are tricky(and most probably has no overall benefit) because the cost IVOPT computed from RTL is far from precise to do such fine granularity tuning. Another point, as Zdenek pointed out, IVOPT doesn't know that pretmp_33/pretmp_34 are going to be used in memory accesses, which means some of address computation can be embedded by appropriate addressing mode. In other words, computation of pretmp_33/pretmp_34 shouldn't be honored when computing overall cost and choosing iv candidates set. Since "_9 + pretmp_33/pretmp_34" is not affine iv, the only way to handle this issue is to lower both memory accesses before IVOPT, into some code like below: : pretmp_23 = (sizetype) i_26; pretmp_32 = pretmp_23 + 1; : # j_27 = PHI _9 = p_6(D)->data; _14 = MEM[_9 + pretmp_32 << 2]; _17 = MEM[_9 + pretmp_23 << 2]; func (_17, _14); j_19 = j_27 + 1; if (count_8(D) > j_19) goto ; else goto ; With this code, the iv uses are biv(i), pretmp_23(i_26) and pretmp_32(i_26+1), and IVOPT won't even add the annoying candidate.
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #33 from Richard Biener --- (In reply to Igor Zamyatin from comment #31) > The problem is that there is a performance regression on i686 for Coremark > test If you can reproduce a testcase please file a new bug for this issue.
[Bug other/59490] [4.9 Regression] cilk-plus failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59490 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c/59491] compiler can't detect if xpression is always fixed value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59491 Richard Biener changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59479] Inlining of static function bloats code size when Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59479 --- Comment #2 from bin.cheng --- I will investigate it later. Just clarifying, the function is called three times by the caller, it would increase code size usually. BTW, could you explain a little about "2nd-order effect"? I am not familiar with the concept. Thanks in advance.
[Bug fortran/59493] New: internal compiler error: Segmentation fault on Class(*) pointer association with GCC 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 Bug ID: 59493 Summary: internal compiler error: Segmentation fault on Class(*) pointer association with GCC 4.8.1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Hi there, I get the segmentation fault on compilation of this code. This compiles with Intel Fortran Compiler. module mode1 implicit none integer :: a=1 type ty_mytype1 integer :: b1=1 end type ty_mytype1 type, extends(ty_mytype1) :: ty_extend integer :: b2=2 end type ty_extend end module mode1 program hello use mode1 implicit none class(ty_mytype1), allocatable,target:: cla1 class(*), pointer :: ptr_cla1 allocate(ty_extend :: cla1) ptr_cla1 => cla1 print *, 'cla1%b1', cla1%b1 end program
[Bug fortran/59484] execute_command_line doesn't play with environment variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59484 --- Comment #3 from Reinhold Straub --- (In reply to Steve Kargl from comment #2) There is obviously no bug :-) Sorry for the noise. And thanks for your very helpful comments!
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-13 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- What was the last working revision?
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Matthias Klose --- 20131201 did succeed. r205573
[Bug tree-optimization/41488] IVOpts cannot coalesce multiple induction variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488 --- Comment #8 from amker at gcc dot gnu.org --- Author: amker Date: Fri Dec 13 11:36:22 2013 New Revision: 205959 URL: http://gcc.gnu.org/viewcvs?rev=205959&root=gcc&view=rev Log: PR tree-optimization/58296 PR tree-optimization/41488 * tree-scalar-evolution.c: Include necessary header files. (simplify_peeled_chrec): New function. (analyze_evolution_in_loop): New static variable. Call simplify_peeled_chrec. * tree-ssa-loop-ivopts.c (mark_bivs): Don't mark peeled IV as biv. (add_old_iv_candidates): Don't add candidate for peeled IV. * tree-affine.h (aff_combination_zero_p): New function. PR tree-optimization/58296 PR tree-optimization/41488 * gcc.dg/tree-ssa/scev-7.c: New test. * gcc.dg/pr41488.c: New test. * g++.dg/pr59445.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr59445.C trunk/gcc/testsuite/gcc.dg/pr41488.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-affine.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/58296] ivopts is unable to handle some loops altered by the loop header copying pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58296 --- Comment #1 from amker at gcc dot gnu.org --- Author: amker Date: Fri Dec 13 11:36:22 2013 New Revision: 205959 URL: http://gcc.gnu.org/viewcvs?rev=205959&root=gcc&view=rev Log: PR tree-optimization/58296 PR tree-optimization/41488 * tree-scalar-evolution.c: Include necessary header files. (simplify_peeled_chrec): New function. (analyze_evolution_in_loop): New static variable. Call simplify_peeled_chrec. * tree-ssa-loop-ivopts.c (mark_bivs): Don't mark peeled IV as biv. (add_old_iv_candidates): Don't add candidate for peeled IV. * tree-affine.h (aff_combination_zero_p): New function. PR tree-optimization/58296 PR tree-optimization/41488 * gcc.dg/tree-ssa/scev-7.c: New test. * gcc.dg/pr41488.c: New test. * g++.dg/pr59445.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr59445.C trunk/gcc/testsuite/gcc.dg/pr41488.c trunk/gcc/testsuite/gcc.dg/tree-ssa/scev-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-affine.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-ivopts.c
[Bug target/58849] complex number, memory is corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58849 --- Comment #2 from otmar.struwe at web dot de --- After updating some parts of the mingw environment (mpfr/gmp/mpc) I am not able to reproduce the described behavior. Now I get: c:\temp\ccWxAggU.o:complex.c:(.text+0xef): undefined reference to `csin' collect2.exe: error: ld returned 1 exit status The compiler is the still the same.
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 --- Comment #3 from H.J. Lu --- GCC generates .cfi_personality 0x9c,DW.ref.__gxx_personality_v0 .cfi_lsda 0x1c,.LLSDA3386 instead of .cfi_personality 0x9b,DW.ref.__gxx_personality_v0 .cfi_lsda 0x1b,.LLSDA3385 Even 64-bit small model doesn't need 64-bit PC relative relocation.
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org --- Reduced test case: implicit none integer, parameter :: nlcdtypes(2) = (/ 11, 12 /) integer :: r !$omp parallel do default(none) do r = 1, 2 print *, nlcdtypes(r) end do end
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #3 from Dominique d'Humieres ---
> r202826 was fixed later by the fix for PR58656 (rnflow regression),
> so your bisection converged on a bogus revision.
OK! I was too focused on the -fwhole-program option. The slowdown after r202826
was with/without this option. r203377 fixed the regression without the option,
but not with it:
[Book15] lin/test% /opt/gcc/gcc4.9p-202825/bin/gfortran -Ofast -fwhole-program
rnflow.f90
[Book15] lin/test% time a.out > /dev/null
12.843u 0.017s 0:12.86 99.9%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-202825/bin/gfortran -Ofast rnflow.f90
[Book15] lin/test% time a.out > /dev/null
12.889u 0.022s 0:12.92 99.8%0+0k 0+0io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-202828/bin/gfortran -Ofast rnflow.f90
[Book15] lin/test% time a.out > /dev/null
17.891u 0.019s 0:17.91 99.9%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-202828/bin/gfortran -Ofast -fwhole-program
rnflow.f90
[Book15] lin/test% time a.out > /dev/null
17.985u 0.021s 0:18.01 99.9%0+0k 4+0io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-203250/bin/gfortran -Ofast rnflow.f90
[Book15] lin/test% time a.out > /dev/null
17.974u 0.020s 0:17.99 100.0%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-203250/bin/gfortran -Ofast -fwhole-program
rnflow.f90
[Book15] lin/test% time a.out > /dev/null
18.182u 0.021s 0:18.21 99.9%0+0k 0+1io 38pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-203492/bin/gfortran -Ofast rnflow.f90
[Book15] lin/test% time a.out > /dev/null
12.856u 0.018s 0:12.87 99.9%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.9p-203492/bin/gfortran -Ofast -fwhole-program
rnflow.f90
[Book15] lin/test% time a.out > /dev/null
18.253u 0.021s 0:18.28 99.9%0+0k 0+0io 39pf+0w
AFAICT the usual incantations ('large-function-growth',
'max-inline-insns-auto', or 'builtin-expect-probability') have no visible
effect on this slowdown with -fwhole-program.
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 CC||janus at gcc dot gnu.org Summary|internal compiler error:|[OOP] ICE: Segfault on |Segmentation fault on |Class(*) pointer |Class(*) pointer|association |association with GCC 4.8.1 | Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed with 4.9 and trunk. Slightly reduced test case: implicit none type ty_mytype1 end type class(ty_mytype1), allocatable,target:: cla1 class(*), pointer :: ptr ptr => cla1 end The backtrace on trunk is: c0.f90: In function ‘MAIN__’: c0.f90:2:0: internal compiler error: Segmentation fault implicit none ^ 0x93662f crash_signal /home/jweil/gcc49/trunk/gcc/toplev.c:336 0x66c231 gfc_get_derived_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2351 0x66c968 gfc_typenode_for_spec(gfc_typespec*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:1112 0x66b223 gfc_sym_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2137 0x66b6e8 gfc_get_function_type(gfc_symbol*) /home/jweil/gcc49/trunk/gcc/fortran/trans-types.c:2797 0x62cb0f build_function_decl /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:1879 0x62e11b gfc_create_function_decl(gfc_namespace*, bool) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:2534 0x634f79 gfc_generate_contained_functions /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:4714 0x634f79 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5541 0x5d5710 translate_all_program_units /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4536 0x5d5710 gfc_parse_file() /home/jweil/gcc49/trunk/gcc/fortran/parse.c:4733 0x611fa5 gfc_be_parse_file /home/jweil/gcc49/trunk/gcc/fortran/f95-lang.c:188
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > Confirmed with 4.9 and trunk. Sorry, that was supposed to be "4.8 and trunk", obviously ;)
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 H.J. Lu changed: What|Removed |Added CC||tmsriram at google dot com --- Comment #4 from H.J. Lu --- It is caused by r205616, which fails to properly save and restore all compiler options.
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493 --- Comment #3 from Hossein Talebi --- Will it be fixed in gfortran 4.8 or 4.9?
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492
--- Comment #5 from H.J. Lu ---
[hjl@gnu-6 gcc]$ cat /tmp/x.cc
void
__throw_runtime_error(const char*) __attribute__((__noreturn__));
unsigned int
__attribute__ ((target("rdrnd")))
__x86_rdrand(void)
{
unsigned int retries = 100;
unsigned int val;
while (__builtin_ia32_rdrand32_step(&val) == 0)
if (--retries == 0)
__throw_runtime_error(("random_device::__x86_rdrand(void)"));
return val;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -c -g -mx32 /tmp/x.cc -std=gnu++11 -fPIC
/tmp/ccTJs5Yu.s: Assembler messages:
/tmp/ccTJs5Yu.s: Error: cannot represent relocation type BFD_RELOC_64_PCREL in
x32 mode
/tmp/ccTJs5Yu.s: Error: cannot represent relocation type BFD_RELOC_64_PCREL in
x32 mode
[hjl@gnu-6 gcc]$
[Bug testsuite/59494] New: [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494
Bug ID: 59494
Summary: [4.9 Regression] FAIL:
gfortran.dg/vect/fast-math-mgrid-resid.f
scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hjl.tools at gmail dot com, howarth at bromo dot med.uc.edu,
jakub at gcc dot gnu.org
The test gfortran.dg/vect/fast-math-mgrid-resid.f fails after r203979 if gcc is
configured with --with-cpu=core* (default for darwin). This is silenced if
-mtune=generic is added to the dg-options list:
--- gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f2013-04-08
15:53:21.0 +0200
+++ ../work/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
2013-12-12 21:51:53.0 +0100
@@ -1,7 +1,7 @@
! { dg-do compile { target i?86-*-* x86_64-*-* } }
! { dg-require-effective-target vect_double }
! { dg-require-effective-target sse2 }
-! { dg-options "-O3 -ffast-math -msse2 -fpredictive-commoning -ftree-vectorize
-fdump-tree-optimized" }
+! { dg-options "-mtune=generic -O3 -ffast-math -msse2 -fpredictive-commoning
-ftree-vectorize -fdump-tree-optimized" }
*** RESID COMPUTES THE RESIDUAL: R = V - AU
[Bug fortran/59493] [OOP] ICE: Segfault on Class(*) pointer association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59493
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Hossein Talebi from comment #3)
> Will it be fixed in gfortran 4.8 or 4.9?
Since I already found out what goes wrong, it will pretty certainly get fixed
on the trunk (to-be-4.9) soon. Since it is not a regression, probably no
backporting to 4.8 will be done.
In any case: The problem was that 'gfc_find_intrinsic_vtab' failed to handle
BT_CLASS. The following patch fixes it (and does some minor cleanup):
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(revision 205948)
+++ gcc/fortran/class.c(working copy)
@@ -2413,29 +2413,34 @@ gfc_find_intrinsic_vtab (gfc_typespec *ts)
gfc_symbol *copy = NULL, *src = NULL, *dst = NULL;
int charlen = 0;
- if (ts->type == BT_CHARACTER && ts->deferred)
+ switch (ts->type)
{
- gfc_error ("TODO: Deferred character length variable at %C cannot "
- "yet be associated with unlimited polymorphic entities");
+case BT_UNKNOWN:
return NULL;
+case BT_DERIVED:
+ return gfc_find_derived_vtab (ts->u.derived);
+case BT_CLASS:
+ return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived);
+case (BT_CHARACTER):
+ if (ts->deferred)
+{
+ gfc_error ("TODO: Deferred character length variable at %C cannot "
+"yet be associated with unlimited polymorphic entities");
+ return NULL;
+}
+ else if (ts->u.cl && ts->u.cl->length
+ && ts->u.cl->length->expr_type == EXPR_CONSTANT)
+charlen = mpz_get_si (ts->u.cl->length->value.integer);
+ break;
+default:
+ break;
}
- if (ts->type == BT_UNKNOWN)
-return NULL;
-
- /* Sometimes the typespec is passed from a single call. */
- if (ts->type == BT_DERIVED)
-return gfc_find_derived_vtab (ts->u.derived);
-
/* Find the top-level namespace. */
for (ns = gfc_current_ns; ns; ns = ns->parent)
if (!ns->parent)
break;
- if (ts->type == BT_CHARACTER && ts->u.cl && ts->u.cl->length
- && ts->u.cl->length->expr_type == EXPR_CONSTANT)
-charlen = mpz_get_si (ts->u.cl->length->value.integer);
-
if (ns)
{
char name[GFC_MAX_SYMBOL_LEN+1], tname[GFC_MAX_SYMBOL_LEN+1];
[Bug c/59495] New: -ftrack-macro-expansion=2 ignores warnings originated from /usr/include headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59495 Bug ID: 59495 Summary: -ftrack-macro-expansion=2 ignores warnings originated from /usr/include headers Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: doront at mellanox dot com $ gcc -Wall -Wextra -Werror include-uapi-linux-netlink.h.test.c -ftrack-macro-expansion=0 include-uapi-linux-netlink.h.test.c: In function 'main': include-uapi-linux-netlink.h.test.c:26:5: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] NLMSG_OK(&auxiliary_netlink_header, active_len)); ^ cc1: all warnings being treated as errors $ gcc -Wall -Wextra -Werror include-uapi-linux-netlink.h.test.c -ftrack-macro-expansion=2 $ $ gcc -Wall -Wextra -Werror -I/builds/kernel_tests_pre_patch_user_headers/include/ include-uapi-linux-netlink.h.test.c -ftrack-macro-expansion=2 In file included from include-uapi-linux-netlink.h.test.c:2:0: include-uapi-linux-netlink.h.test.c: In function 'main': /builds/kernel_tests_pre_patch_user_headers/include/linux/netlink.h:89:24: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] (nlh)->nlmsg_len <= (len)) ^ include-uapi-linux-netlink.h.test.c:26:5: note: in expansion of macro 'NLMSG_OK' NLMSG_OK(&auxiliary_netlink_header, active_len)); ^ cc1: all warnings being treated as errors $
[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- I could reproduce this.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #4 from rguenther at suse dot de ---
"dominiq at lps dot ens.fr" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
>
>--- Comment #3 from Dominique d'Humieres
>---
>> r202826 was fixed later by the fix for PR58656 (rnflow regression),
>> so your bisection converged on a bogus revision.
>
>OK! I was too focused on the -fwhole-program option. The slowdown after
>r202826
>was with/without this option. r203377 fixed the regression without the
>option,
>but not with it:
Still the regression must appear with a different revision. The one you cited
has nothing to do with -fwhole-program.
Richard.
>[Book15] lin/test% /opt/gcc/gcc4.9p-202825/bin/gfortran -Ofast
>-fwhole-program
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>12.843u 0.017s 0:12.86 99.9%0+0k 0+0io 0pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-202825/bin/gfortran -Ofast
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>12.889u 0.022s 0:12.92 99.8%0+0k 0+0io 41pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-202828/bin/gfortran -Ofast
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>17.891u 0.019s 0:17.91 99.9%0+0k 0+0io 0pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-202828/bin/gfortran -Ofast
>-fwhole-program
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>17.985u 0.021s 0:18.01 99.9%0+0k 4+0io 41pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-203250/bin/gfortran -Ofast
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>17.974u 0.020s 0:17.99 100.0%0+0k 0+0io 0pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-203250/bin/gfortran -Ofast
>-fwhole-program
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>18.182u 0.021s 0:18.21 99.9%0+0k 0+1io 38pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-203492/bin/gfortran -Ofast
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>12.856u 0.018s 0:12.87 99.9%0+0k 0+0io 0pf+0w
>[Book15] lin/test% /opt/gcc/gcc4.9p-203492/bin/gfortran -Ofast
>-fwhole-program
>rnflow.f90
>[Book15] lin/test% time a.out > /dev/null
>18.253u 0.021s 0:18.28 99.9%0+0k 0+0io 39pf+0w
>
>AFAICT the usual incantations ('large-function-growth',
>'max-inline-insns-auto', or 'builtin-expect-probability') have no
>visible
>effect on this slowdown with -fwhole-program.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 --- Comment #5 from Dominique d'Humieres --- > Still the regression must appear with a different revision. > The one you cited has nothing to do with -fwhole-program. I see the slowdown with -fwhole-program for all the revisions I have tested starting at r202826 up to r205891. If this has been fixed and broken again, bissection won't give reliable results and I am not planning to test the 3000+ revisions in that range.
[Bug c/59495] -ftrack-macro-expansion=2 ignores warnings originated from /usr/include headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59495
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek ---
I'd say it's because in maybe_unwind_expanded_macro_loc we've got
/* Walk LOC_VEC and print the macro expansion trace, unless the
first macro which expansion triggered this trace was expanded
inside a system header. */
int saved_location_line =
expand_location_to_spelling_point (diagnostic->location).line;
if (!LINEMAP_SYSP (map))
FOR_EACH_VEC_ELT (loc_vec, ix, iter)
{
...
}
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #6 from H.J. Lu --- We should never change -fPIC. This patch fixes it: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 9fd6baa..2d79ee6 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -4333,6 +4333,9 @@ ix86_function_specific_restore (struct gcc_options *opts, unsigned int ix86_arch_mask; int i; + /* We don't change -fPIC. */ + opts->x_flag_pic = flag_pic; + ix86_arch = (enum processor_type) ptr->arch; ix86_schedule = (enum attr_cpu) ptr->schedule; ix86_tune = (enum processor_type) ptr->tune;
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Forgot to add the pointer to http://gcc.gnu.org/ml/gcc-regression/2013-10/msg00205.html.
[Bug fortran/59484] execute_command_line doesn't play with environment variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59484 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from kargl at gcc dot gnu.org --- Thanks for the bug report. It's better to report something that isn't a bug than to not to report it at all.
[Bug target/59492] [4.9 Regression] bootstrap failure on x32 when configured with --enable-libstdcxx-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 --- Comment #7 from H.J. Lu --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01253.html
[Bug bootstrap/59496] New: [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496 Bug ID: 59496 Summary: [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, jsm28 at gcc dot gnu.org, mpolacek at gcc dot gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Bootstrap fails on powerpc-apple-darwin9 after r205685 and is not fixed by r205705: /opt/gcc/rel_build/./prev-gcc/xg++ -B/opt/gcc/rel_build/./prev-gcc/ -B/opt/gcc/gcc4.9r/powerpc-apple-darwin9.8.0/bin/ -nostdinc++ -B/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -B/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs -I/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/opt/gcc/rel_work/libstdc++-v3/libsupc++ -L/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -L/opt/gcc/rel_build/prev-powerpc-apple-darwin9.8.0/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -Ic-family -I../../rel_work/gcc -I../../rel_work/gcc/c-family -I../../rel_work/gcc/../include -I./../intl -I../../rel_work/gcc/../libcpp/include -I/opt/mp/include -I../../rel_work/gcc/../libdecnumber -I../../rel_work/gcc/../libdecnumber/dpd -I../libdecnumber -I../../rel_work/gcc/../libbacktrace -DCLOOG_INT_GMP -I/opt/mp/include -o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../rel_work/gcc/c-family/c-common.c ../../rel_work/gcc/c-family/c-common.c: In function 'tree_node* c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)': ../../rel_work/gcc/c-family/c-common.c:5009:9: error: unused variable 'field' [-Werror=unused-variable] tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, ^ cc1plus: all warnings being treated as errors The problem comes from the fact that ADJUST_FIELD_ALIGN is defined in gcc/config/rs6000/darwin.h as #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \ (TARGET_ALIGN_NATURAL ? (COMPUTED)\ : (COMPUTED) == 128 ? 128\ : MIN ((COMPUTED), 32)) and does not use FIELD, as seen in the preprocessed file ... tree field = build_decl_stat (((source_location) 0), FIELD_DECL, (tree) __null, type ) ; field_align = ((global_options.x_rs6000_alignment_flags & 0x0001) ? (field_align) : (field_align) == 128 ? 128 : (((field_align)) < (32) ? ((field_align)) : (32))); align = ((align) < (field_align) ? (align) : (field_align)); ... I have fixed the problem with the following patch: --- gcc/c-family/c-common.c2013-12-11 13:43:47.0 +0100 +++ ../work/gcc/c-family/c-common.c2013-12-08 00:14:27.0 +0100 @@ -5002,7 +5006,7 @@ c_sizeof_or_alignof_type (location_t loc #endif unsigned int field_align = align; #ifdef ADJUST_FIELD_ALIGN - tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, + tree __attribute__((unused)) field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, type); field_align = ADJUST_FIELD_ALIGN (field, field_align); #endif Yes I know, the line is too long and patches should go to gcc-patches. I'll do it if there is a consensus that it is the right fix.
[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-13 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- from the point of view of powerpc-darwin, this is the right fix (it doesn't need to act on FIELD in this context).
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Markus Trippelsdorf --- I'm still getting: ... libreoffice-4.1.3.2/canvas/source/factory/cf_service.cxx:528:1: warning: macro "__code_model_small__" is not used [-Wunused-macros] } ^
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
Dominique d'Humieres changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||burnus at gcc dot gnu.org,
||iains at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #20 from Dominique d'Humieres ---
This PR has reappeared after r205679 with warnings of the kind
warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_namelist_item: attr = AT_namelist_item form = FORM_ref4
They are silenced with the following change of the regexp added at r167683:
--- gcc/testsuite/lib/prune.exp2013-04-26 10:21:37.0 +0200
+++ ../work/gcc/testsuite/lib/prune.exp2013-12-11 16:42:00.0 +0100
@@ -59,7 +59,7 @@ proc prune_gcc_output { text } {
# Ignore harmless warnings from Xcode 3.2.x.
regsub -all "(^|\n)\[^\n\]*ld: warning: can't add line info to anonymous
symbol\[^\n\]*" $text "" text
-regsub -all "(^|\n)\[^\n\]*warning:
DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*_bound\[^\n\]*FORM_ref4\[^\n\]*"
$text "" text
+regsub -all "(^|\n)\[^\n\]*warning:
DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*FORM_ref4\[^\n\]*"
$text "" text
regsub -all "(^|\n)\[^\n\]*warning:\[^\n\]*TAG_variable:
AT_location\[^\n\]*didn't have valid function low pc\[^\n\]*" $text "" text
# Ignore harmless warnings from Xcode 4.0.
I hope this change will survive any fix for pr59438!
[Bug tree-optimization/42632] [4.5 Regression] unimplemented: inlining failed in call to ‘pskb_trim’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42632 Bug 42632 depends on bug 45685, which changed state. Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug other/46542] GCC 4.7 pending patches meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542 Bug 46542 depends on bug 45685, which changed state. Bug 45685 Summary: [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/45685] [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Jeffrey A. Law --- Resolved by recent checkin.
[Bug tree-optimization/45685] [4.7/4.8/4.9 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 --- Comment #27 from Jeffrey A. Law --- Author: law Date: Fri Dec 13 16:34:39 2013 New Revision: 205963 URL: http://gcc.gnu.org/viewcvs?rev=205963&root=gcc&view=rev Log: PR tree-optimization/45685 * tree-ssa-phiopt.c (neg_replacement): New function. (tree_ssa_phiopt_worker): Call it. PR tree-optimization/45685 * gcc.dg/tree-ssa/pr45685.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45685.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Manuel López-Ibáñez changed: What|Removed |Added CC||doront at mellanox dot com --- Comment #13 from Manuel López-Ibáñez --- *** Bug 59495 has been marked as a duplicate of this bug. ***
[Bug c/59495] -ftrack-macro-expansion=2 ignores warnings originated from /usr/include headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59495 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Manuel López-Ibáñez --- See the discussion in PR55252, specially comments #3 and #9. *** This bug has been marked as a duplicate of bug 55252 ***
[Bug target/59492] [4.9 Regression] multiarch function versioning fails to preserve -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59492 H.J. Lu changed: What|Removed |Added Priority|P3 |P2 Summary|[4.9 Regression] bootstrap |[4.9 Regression] multiarch |failure on x32 when |function versioning fails |configured with |to preserve -fPIC |--enable-libstdcxx-debug|
[Bug c/59451] The compiler does not accept two structures, when the first one of them have the same name as the structure, as function parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59451 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek --- I'd say this is invalid, an identifier declared as a typedef name can't be redeclared as a parameter.
[Bug tree-optimization/59149] diagnose_tm_1 calls flags_from_decl_or_type on an ADDR_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59149 --- Comment #3 from Aldy Hernandez --- Author: aldyh Date: Fri Dec 13 17:50:18 2013 New Revision: 205967 URL: http://gcc.gnu.org/viewcvs?rev=205967&root=gcc&view=rev Log: PR tree-optimization/59149 * calls.c (flags_from_decl_or_type): Fail on non decl or type. * trans-mem.c (diagnose_tm_1): Do not call flags_from_decl_or_type if no type or decl. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/trans-mem.c
[Bug tree-optimization/59149] diagnose_tm_1 calls flags_from_decl_or_type on an ADDR_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59149 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Aldy Hernandez --- fix committed
[Bug c++/59498] New: Pack expansion error in template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
Bug ID: 59498
Summary: Pack expansion error in template alias
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
GCC Version
---
gcc-4.9 (GCC) 4.9.0 20131201 (experimental)
Installed with Homebrew.
System
--
OS X 10.8.5
Command line to trigger the bug
---
gcc-4.9 -std=c++11 -Wall -Wextra -pedantic -o /dev/null -c
template_alias_bug.cpp
Minimal code to reproduce
-
template
using alias = T;
template
using variadic_alias = alias;
using Fail = variadic_alias;
int main() { }
Error message
-
template_alias_bug.cpp:9:34: error: pack expansion argument for non-pack
parameter 'T' of alias template 'template using alias = T'
using variadic_alias = alias;
^
template_alias_bug.cpp:5:11: note: declared here
template
^
template_alias_bug.cpp:11:14: error: expected type-specifier before
'variadic_alias'
using Fail = variadic_alias;
^
Possibly related
Bug 58856
Comments
Clang compiles the code just fine and I don't see any obvious reason why that
would be invalid C++11 (I could be mistaken), so I think that's a GCC bug.
[Bug c++/59499] New: Probably optimization error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59499
Bug ID: 59499
Summary: Probably optimization error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: desoft at freemail dot gr
definefunc(L"int-",[](){stack.push(-(stack.pop())+(stack.pop()));});
The above function is defined in order to subtract the tos of the stack from
the lower number, but the result is wrong.
In order to have it work correctly I have to redefine it like:
{int i2=stack.pop();int i1=stack.pop();stack.push(i1-i2);}
I have changed parentheses and order keeping the same semantics but nothing
changed.
It is a reproducible bug under current circumstances.
I don´t send all the code because it is big, but I may create a complete
example f that is felt as needed.
[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477
--- Comment #2 from Vladimir Makarov ---
Reload pass gives
b.i: In function ‘void test1(_Bit_iterator)’:
b.i:90:1: error: unable to find a register to spill in class ‘CREG’
}
^
b.i:90:1: error: this is the insn:
(insn 29 43 30 2 (parallel [
(set (reg:DI 37 r8)
(ashift:DI (reg:DI 37 r8 [92])
(subreg:QI (reg:SI 90 [ _M_offset ]) 0)))
(clobber (reg:CC 17 flags))
]) b.i:54 528 {*ashldi3_1}
(expr_list:REG_DEAD (reg:DI 37 r8 [92])
(expr_list:REG_DEAD (reg:SI 90 [ _M_offset ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
b.i:90:1: internal compiler error: in spill_failure, at reload1.c:2106
0xaf796a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/cygnus/vmakarov/build1/trunk2/gcc/gcc/rtl-error.c:109
0xaf63d3 spill_failure
/home/cygnus/vmakarov/build1/trunk2/gcc/gcc/reload1.c:2106
0xaf63d3 find_reload_regs
/home/cygnus/vmakarov/build1/trunk2/gcc/gcc/reload1.c:2032
0xaf63d3 select_reload_regs
...
Before combiner we have:
28: cx:DI=0
29: r8:SI=r97:DI#0
REG_DEAD r97:DI
30: dx:DI=r103:DI
REG_DEAD r103:DI
REG_EQUAL frame:DI-0x2
31: si:DI=r104:DI
REG_DEAD r104:DI
REG_EQUAL frame:DI-0x1
32: di:DI=r98:DI
REG_DEAD r98:DI
REG_EQUAL frame:DI-0x20
33: call
[`_Z9__find_ifI16reverse_iteratorI13_Bit_iteratorE17_Iter_equals_iterIS2_EET_S5_S5_T0_']
argc:0
REG_DEAD r8:SI
REG_DEAD di:DI
REG_DEAD si:DI
REG_DEAD cx:DI
REG_DEAD dx:DI
After combiner we have:
28: cx:DI=0
29: {r8:DI=r92:DI<
[Bug c++/59500] New: Bogus maybe-unintialized warning due to optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500
Bug ID: 59500
Summary: Bogus maybe-unintialized warning due to optimizations
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
I would have sworn that there was a bug open about this, but I can't find it,
and this bug has been annoying me for years.
Compiling this code with g++ -O2 -Wall:
#ifndef __cplusplus
#include
#endif
extern int intval();
extern bool cond();
int main()
{
bool valid = false;
int value;
if (cond()) {
valid = true;
value = intval();
}
while (!valid || intval() < value)
;
return 0;
}
says:
trivial_uninit_warning.cc: In function ‘int main()’:
trivial_uninit_warning.cc:18:17: warning: ‘value’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
while (!valid || intval() < value)
Oddly, compiling exactly the same code in C (instead of C++) does not warn.
This seems quite sensitive to exactly what the code is doing. IIRC the issue
is that the "load" of value is moved ahead of the check of valid by the
optimizer (which is entirely valid), but then that load appears to access an
uninitialized value and warns.
[Bug fortran/58113] [4.9 Regression] gfortran.dg/round_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58113 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- Patch applied.
[Bug libfortran/58015] FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol "nextafterl"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 --- Comment #6 from Eric Botcazou --- Why not just adapt the existing implementation of nextafterf to long double?
[Bug libfortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59313 Eric Botcazou changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Eric Botcazou --- The link failure is still there on Solaris 9, probably because some long double routines are missing from libm: (botcazou@nile) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.9/sparc-sun-solaris2.9/libgfortran $ grep HAVE_ERFCL *.h config.h:/* #undef HAVE_ERFCL */ (botcazou@nile) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.9/sparc-sun-solaris2.9/libgfortran $ grep HAVE_EXPL *.h config.h:/* #undef HAVE_EXPL */
[Bug tree-optimization/59501] New: Vector Gather with GCC 4.9 2013-12-08 Snapshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501
Bug ID: 59501
Summary: Vector Gather with GCC 4.9 2013-12-08 Snapshot
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie at witherden dot org
Compiling the following snippet with the 2013-12-08 shapshot of 4.9:
typedef double v4d __attribute__((vector_size(32)));
v4d gather(double *base, unsigned *offt)
{
v4d tmp = { base[offt[0]], base[offt[1]], base[offt[2]], base[offt[3]]
};
return tmp;
}
with flags: -std=c++11 -Ofast -march=core-avx2 emits the following ASM:
<_Z6gatherPdPj>:
0: 8b 16 mov(%rsi),%edx
2: 4c 8d 54 24 08 lea0x8(%rsp),%r10
7: 48 83 e4 e0 and$0xffe0,%rsp
b: 44 8b 46 08 mov0x8(%rsi),%r8d
f: 41 ff 72 f8 pushq -0x8(%r10)
13: 55 push %rbp
14: 8b 46 04mov0x4(%rsi),%eax
17: 48 89 e5mov%rsp,%rbp
1a: 8b 4e 0cmov0xc(%rsi),%ecx
1d: 41 52 push %r10
1f: 41 5a pop%r10
21: c4 a1 7b 10 14 c7 vmovsd (%rdi,%r8,8),%xmm2
27: c5 fb 10 1c d7 vmovsd (%rdi,%rdx,8),%xmm3
2c: c5 e9 16 0c cf vmovhpd (%rdi,%rcx,8),%xmm2,%xmm1
31: 5d pop%rbp
32: c5 e1 16 04 c7 vmovhpd (%rdi,%rax,8),%xmm3,%xmm0
37: c4 e3 7d 18 c1 01 vinsertf128 $0x1,%xmm1,%ymm0,%ymm0
3d: 49 8d 62 f8 lea-0x8(%r10),%rsp
41: c3 retq
which appears to be a regression when compared with 4.8.2:
<_Z6gatherPdPj>:
0: 8b 16 mov(%rsi),%edx
2: 44 8b 46 08 mov0x8(%rsi),%r8d
6: 8b 46 04mov0x4(%rsi),%eax
9: 8b 4e 0cmov0xc(%rsi),%ecx
c: c5 fb 10 1c d7 vmovsd (%rdi,%rdx,8),%xmm3
11: c4 a1 7b 10 14 c7 vmovsd (%rdi,%r8,8),%xmm2
17: c5 e1 16 0c c7 vmovhpd (%rdi,%rax,8),%xmm3,%xmm1
1c: c5 e9 16 04 cf vmovhpd (%rdi,%rcx,8),%xmm2,%xmm0
21: c4 e3 75 18 c0 01 vinsertf128 $0x1,%xmm0,%ymm1,%ymm0
27: c3 retq
[Bug fortran/59502] New: ICE on invalid on pointer assignment to non-pointer CLASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502 Bug ID: 59502 Summary: ICE on invalid on pointer assignment to non-pointer CLASS Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com The following causes an ICE with gfortran 4.9 (r205975): module cp type :: d end type d type, public :: p class(d) :: pd end type p contains function pc(pd) implicit none type(p) :: pc class(d), intent(in), target :: pd pc%pd => pd return end function pc end module cp $ gfortran -v Using built-in specs. COLLECT_GCC=/opt/gcc-trunk/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20131213 (experimental) (GCC) $ gfortran test.F90 -o test.o -c f951: internal compiler error: Segmentation fault 0x9f251f crash_signal ../../gcc-trunk/gcc/toplev.c:336 0x5ae283 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc-trunk/gcc/fortran/primary.c:2044 0x5ae70d match_variable ../../gcc-trunk/gcc/fortran/primary.c:3304 0x58fe19 gfc_match(char const*, ...) ../../gcc-trunk/gcc/fortran/match.c:1116 0x590fdc gfc_match_assignment() ../../gcc-trunk/gcc/fortran/match.c:1293 0x5a5239 match_word ../../gcc-trunk/gcc/fortran/parse.c:65 0x5a61d1 match_word ../../gcc-trunk/gcc/fortran/parse.c:327 0x5a61d1 decode_statement ../../gcc-trunk/gcc/fortran/parse.c:327 0x5a7741 next_free ../../gcc-trunk/gcc/fortran/parse.c:784 0x5a7741 next_statement ../../gcc-trunk/gcc/fortran/parse.c:977 0x5a8103 parse_spec ../../gcc-trunk/gcc/fortran/parse.c:2768 0x5a9f78 parse_progunit ../../gcc-trunk/gcc/fortran/parse.c:4148 0x5aa2fc parse_contained ../../gcc-trunk/gcc/fortran/parse.c:4087 0x5ab50d parse_module ../../gcc-trunk/gcc/fortran/parse.c:4350 0x5ab50d gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4652 0x5e8ff5 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:188 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. The code is invalid as "pd" should have either allocatable or pointer attributes. If the pointer assignment "pc%pd => pd" is removed then compilation correctly fails with: $ gfortran test.F90 -o test.o -c test.F90:7.19: class(d) :: pd 1 Error: Component 'pd' with CLASS at (1) must be allocatable or pointer
[Bug sanitizer/59503] New: Bogus integer-overflow error with long long with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59503
Bug ID: 59503
Summary: Bogus integer-overflow error with long long with -m32
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
We wrongly issue runtime error on:
int
main (void)
{
long long int a = 14;
long int b = 9;
if ((a - b) != 5)
__builtin_abort ();
return 0;
}
$ gcc -O0 -fsanitize=signed-integer-overflow -m32 bug.c
$ ./a.out
bug.c:6:10: runtime error: signed integer overflow: 14 - 9 cannot be
represented in type 'long long int'
Aborted
This happens on PPC64 as well, as the bug is in generic handling of add/sub
instrumentation.
[Bug sanitizer/59503] Bogus integer-overflow error with long long with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59503 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-14 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- I have a fix.
[Bug c++/59504] New: "Internal compiler error: segmentation fault" in GCC 4.8.1 with -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59504 Bug ID: 59504 Summary: "Internal compiler error: segmentation fault" in GCC 4.8.1 with -fprofile-use Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chbaker0 at gmail dot com Created attachment 31430 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31430&action=edit Sources and -fprofile-generate output files GCC 4.8.1 crashes upon attempting to compile C++11 code with -fprofile-use and any optimization level, -O and higher. Logs: x86_64-w64-mingw32-g++.exe -std=c++11 -Wall -O -fprofile-use -IC:\Development\Libraries\glew-1.10.0\include -IC:\Development\Libraries\glfw-x86-64\include -IC:\Development\Libraries\glm -IC:\Development\Libraries\glsdk_0_5_2\glutil\include -c C:\Development\Projects\OpenGL\Practice\Includes.h -o Includes.h.gch x86_64-w64-mingw32-g++.exe -std=c++11 -Wall -O -fprofile-use -IC:\Development\Libraries\glew-1.10.0\include -IC:\Development\Libraries\glfw-x86-64\include -IC:\Development\Libraries\glm -IC:\Development\Libraries\glsdk_0_5_2\glutil\include -c C:\Development\Projects\OpenGL\Practice\main.cpp -o obj\Release\main.o C:\Development\Projects\OpenGL\Practice\main.cpp: In static member function 'static void std::_Function_base::_Base_manager<_Functor>::_M_destroy(std::_Any_data&, std::false_type) [with _Functor = std::function)>; std::false_type = std::integral_constant]': C:\Development\Projects\OpenGL\Practice\main.cpp:213:1: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/59504] "Internal compiler error: segmentation fault" in GCC 4.8.1 with -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59504 Collin Baker changed: What|Removed |Added CC||chbaker0 at gmail dot com --- Comment #1 from Collin Baker --- Same code builds fine with -O and higher and without -fprofile-use, or with -fprofile-use and without -O or higher
[Bug lto/59505] New: gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 Bug ID: 59505 Summary: gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Created attachment 31431 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31431&action=edit gcc-4.8.2-64bit-config.log gzipped libtool: link: ranlib .libs/libglsl.a libtool: link: rm -fr .libs/libglsl.lax libtool: link: ( cd ".libs" && rm -f "libglsl.la" && ln -s "../libglsl.la" "libglsl.la" ) /bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -m32 -fvisibility=hidden -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -Wall -fno-strict-aliasing -fno-builtin-memcmp -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o glsl_compiler hash_table.o imports.o prog_hash_table.o symbol_table.o standalone_scaffolding.o main.o libglsl.la libtool: link: x86_64-pc-linux-gnu-g++ -m32 -fvisibility=hidden -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -Wall -fno-strict-aliasing -fno-builtin-memcmp -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o glsl_compiler hash_table.o imports.o prog_hash_table.o symbol_table.o standalone_scaffolding.o main.o -Wl,--as-needed ./.libs/libglsl.a /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `_mesa_new_shader': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/standalone_scaffolding.cpp:76: undefined reference to `rzalloc_size' /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `main': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:337: undefined reference to `rzalloc_size' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:339: undefined reference to `ralloc_strdup' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:343: undefined reference to `reralloc_array_size' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:347: undefined reference to `rzalloc_size' /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `load_text_file': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:216: undefined reference to `ralloc_size' /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `operator new': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/glsl_parser_extras.h:80: undefined reference to `ralloc_size' /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `compile_shader': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:279: undefined reference to `_mesa_glsl_parse_state::_mesa_glsl_parse_state(gl_context*, unsigned int, void*)' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:281: undefined reference to `_mesa_glsl_compile_shader' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:285: undefined reference to `_mesa_print_ir' /var/tmp/portage/media-libs/mesa-10.0.1/temp/cc0tEQQs.ltrans0.ltrans.o: In function `main': /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:392: undefined reference to `ralloc_free' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:392: undefined reference to `ralloc_free' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:392: undefined reference to `ralloc_free' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:394: undefined reference to `ralloc_free' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:395: undefined reference to `_mesa_glsl_release_types' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:396: undefined reference to `_mesa_glsl_release_builtin_functions()' /var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa-10.0.1-x86/src/glsl/../../src/glsl/main.cpp:384: undefined reference to `link_shaders(gl_context*, gl_shader_program*)' collect2: error: ld returned 1 exit status Makefile:1136: recipe for target 'glsl_compiler' failed gmake[3]: *** [glsl_compiler] Error 1 gmake[3]: Leaving directory '/var/tmp/portage/media-libs/mesa-10.0.1/work/Mesa
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #2 from David Kredba --- Created attachment 31433 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31433&action=edit gcc-4.8.2-64bit-build.log gzipped
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #3 from David Kredba --- Created attachment 31434 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31434&action=edit gcc-4.8.2-32bit-build.log gzipped
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #1 from David Kredba --- Created attachment 31432 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31432&action=edit gcc-4.8.2-32bit-config.log gzipped
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #5 from David Kredba --- Created attachment 31436 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31436&action=edit 32bit-config.log gzipped
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #4 from David Kredba --- Created attachment 31435 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31435&action=edit Build.log gzipped
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
--- Comment #11 from Jan Kratochvil ---
Similar inappropriate warning is generated for typedef-vs-variable as reported
now by Adam Jackson. Again a mistaken use cannot harm as it causes other
errors. And clang also does not warn on it.
int main(void) {
typedef int x;
{
int x = 0;
return x;
}
}
