Re: build error in libgcc
2013/6/22 Ian Lance Taylor i...@google.com: On Sat, Jun 22, 2013 at 12:17 AM, Chung-Ju Wu jasonw...@gmail.com wrote: Like this? === --- libgcc/Makefile.in (revision 200306) +++ libgcc/Makefile.in (working copy) @@ -121,8 +121,8 @@ .PHONY: all clean clean: - -rm -f auto-target.h libgcc_tm.h libgcc.map - -rm -f libgcc_tm.stamp stamp-h stmp-ldirs + -rm -f libgcc_tm.h libgcc.map + -rm -f libgcc_tm.stamp stmp-ldirs -rm -f *$(objext) -rm -f *.dep -rm -f *.a @@ -131,6 +131,8 @@ @$(MULTICLEAN) multi-clean DO=clean distclean: clean @$(MULTICLEAN) multi-clean DO=distclean + -rm -f auto-target.h + -rm -f stamp-h -rm -f *~ Makefile config.cache config.status multilib.out -rm -f config.log maintainer-clean realclean: distclean Hi, Mike, would you try this revised one? :) This patch is OK with a ChangeLog entry. Thanks. Ian Thanks for the review and approval. The patch and a ChangeLog has been posted on: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01420.html Best regards, jasonwucj
this code in fold-const.c:fold_single_bit_test looks wrong to me
if (TREE_CODE (inner) == RSHIFT_EXPR
TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST
TREE_INT_CST_HIGH (TREE_OPERAND (inner, 1)) == 0
bitnum TYPE_PRECISION (type)
0 compare_tree_int (TREE_OPERAND (inner, 1),
bitnum - TYPE_PRECISION (type)))
{
bitnum += TREE_INT_CST_LOW (TREE_OPERAND (inner, 1));
inner = TREE_OPERAND (inner, 0);
}
in particular, in the last stanza of the test
TREE_OPERAND (inner, 1) is a positive number from the second stanza.
bitnum is also always positive and less than the TYPE_PRECISION (type)
from the third stanza,
so bitnum - TYPE_PRECISION (type) is always negative,
so the compare will always be positive, so this code will never be executed.
it is hard to believe that this is what you want.
kenny
Re: GCC 4.6 missing plugin headers
On Wed, 19 Jun 2013 10:47:09 +0100 Alex Leach albl...@york.ac.uk wrote: Are there any further releases planned for the 4.6 branch? Would a patch be accepted for this? I've got the 4.6 branch checked out in git, but don't know exactly where an edit would be needed.. Are there any reasons why this header is not installed with 4.6? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.6.4/gentoo/76_all_4.7.0_c-family-headers.patch?revision=1.1view=markup -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This change fixed the failures for me:
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/gather_scatter.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/gather_scatter.c
@@ -6,11 +6,11 @@
#include stdio.h
#endif
+float array4[NUMBER][NUMBER][NUMBER][NUMBER];
int main(void)
{
int array[NUMBER][NUMBER], array2[NUMBER], array3[NUMBER], x = 0, y;
- int x_correct, y_correct, ii, jj = 0;
- float array4[NUMBER][NUMBER][NUMBER][NUMBER];
+ int x_correct, y_correct, ii, jj = 0, kk = 0, ll = 0;
for (ii = 0; ii NUMBER; ii++)
{
for (jj = 0; jj NUMBER; jj++)
Thanks for the fix.
[Bug tree-optimization/57702] Reassoc missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Another example:
unsigned int foo (unsigned int x, unsigned int y)
{
x += y;
x += y;
x += y;
x += y;
x += y;
return x;
}
Seems for the x += 7 * y; x += 12 * y; case it is undistribute_ops_list that
performs this optimization. For non-wrapping integers we give up very early,
can_reassociate_p returns false and we don't try anything, perhaps with care we
could try at least undistribution, provided that we are very careful not to
reorder anything, only undistribute adjacent operations. For unsigned
integers,
we give up because we never consider an SSA_NAME to be 1 * SSA_NAME for the
purposes of undistribution.
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Martin Liška from comment #0) SandboxSyscall calls SyscallAsm that is an assembler function defined in the same file: syscall.cc. If it is in a toplevel asm() then this is a know missed feature of toplevel asm()s - you cannot specify what symbols they declare. Can you attach preprocessed source of syscall.cc?
[Bug tree-optimization/57702] Reassoc missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57702 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, well. reassoc needs an audit on places where we may not associate blindly for TYPE_OVERFLOW_UNDEFINED/TRAPS. Its general machinery is just not prepared for such limitation (for example ops list sorting cannot be done in general, linearization cannot be done in general, etc.)
[Bug tree-optimization/57705] New: Non-constant step induction vars not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57705
Bug ID: 57705
Summary: Non-constant step induction vars not vectorized
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: jakub at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
int a[1024] __attribute__ ((aligned (32)));
void
bar (int k, int m)
{
int i, k2 = k;
for (i = 0; i 1024; i++)
{
a[i] = k2;
k2 += m + 1;
}
}
isn't vectorized, although it seems fairly easy to handle these.
[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 25 08:21:31 2013 New Revision: 200391 URL: http://gcc.gnu.org/viewcvs?rev=200391root=gccview=rev Log: 2013-06-25 Richard Biener rguent...@suse.de PR middle-end/56977 * passes.c (init_optimization_passes): Move pass_fold_builtins and pass_dce earlier with -Og. * gcc.dg/pr56977.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr56977.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Allan McRae from comment #15)
I tried with -include foo.h and a breakpoint in push_command_line_include...
I just stepped through from that breakpoint and saw cpp_push_default_include
being called for both stdc-predef.h and foo.h. That also gives the correct
output.
# gcc-4.9 -include foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
What is the trace of LC_ messages produced here? It seems the -imacros code is
missing something. Actually, if you could attach the corresponding gdb session
like you did earlier, it would be helpful to compare both.
[Bug c++/57699] Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Paolo already patched libstdc++ and there's nothing to fix in eCos.
The point is that if I write
extern C {
void f();
}
in a libstdc++ header it should mean what the C++ standard says it means.
The implicit extern C kluge is for system headers not known to be C++
compatible, but libstdc++ headers are (of course) C++ compatible, so applying
the kluge is useless and causes bugs when people try to write valid C++, only
to find it has a different meaning on different platforms.
[Bug libstdc++/57704] std::char_traitschar::lt is not standards-compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57704 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/57682] Uniform initialization syntax rejected in function-try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01352.html
[Bug c++/57645] [4.8/4.9 Regression] Explicitly-declared destructor with no exception specification is always noexcept(true)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Created attachment 30357 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30357action=edit An extended set of tests
[Bug middle-end/45579] Re-enable IPA-CP for fn spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579 Bug 45579 depends on bug 43665, which changed state. Bug 43665 Summary: INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/44589] Missing not-set diagnositic (as READ arguments are clobbered)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44589 Bug 44589 depends on bug 43665, which changed state. Bug 43665 Summary: INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can this be closed? No answer since almost a year. Closing as FIXED.
[Bug middle-end/23169] Fortran INTENT information not used in the middle-end for optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR seems to have been fixed by revision 165559 or earlier. Closing as FIXED. Please reopen if I am wrong.
[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per TYPE_QUAL_RESTRICT is now supported, see http://gcc.gnu.org/ml/fortran/2009-08/msg00208.html TYPE_QUAL_CONST is to my knowledge a no op, for QUAL_VOLATILE, I have not checked whether it is already (correctly) used or not - according to comment 4 they are. Closing as FIXED. Please reopen if I am wrong.
[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Done now.
[Bug fortran/24546] [meta-bug] gfortran debugging problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546 Bug 24546 depends on bug 29697, which changed state. Bug 29697 Summary: gfortran should use TYPE_QUAL_CONST etc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR fixed by revision 165559 or not?
[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still no warning at revision 200371.
[Bug fortran/50331] -Wuninitialized and variable passed to WRITE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50331 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200371.
[Bug fortran/24546] [meta-bug] gfortran debugging problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546 Bug 24546 depends on bug 23280, which changed state. Bug 23280 Summary: gfortran does not emit DW_AT_entry_point (dwarf-2) debugging info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/23280] gfortran does not emit DW_AT_entry_point (dwarf-2) debugging info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can this PR be closed given that PR 43414 is fixed? If not, could you point out what is missing? No answer since more than two years. Closing as FIXED.
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this fixed by revision 158612? If yes, please close this PR as FIXED.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de ---
Here's a reduced example:
% cat test.ii
typedef bool (*IsAcceptableThis) (const int );
inline int
fn1 (IsAcceptableThis p1)
{
p1 (0);
return 0;
}
__attribute__ ((always_inline))
inline bool fn2 (const int )
{
return 0;
}
void
fn3 ()
{
fn1 (fn2);
}
% g++ -c -O2 test.ii
test.ii: In function ‘void fn3()’:
test.ii:10:13: error: inlining failed in call to always_inline ‘bool fn2(const
int)’: indirect function call with a yet undetermined callee
inline bool fn2 (const int )
^
test.ii:5:11: error: called from here
p1 (0);
^
[Bug fortran/40920] Derived type with BIND(C) - rejected as argument.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT this PR has been fixed from 4.6 up to trunk (4.9). Closing as FIXED. Please reopen if I am missing something.
[Bug fortran/32630] [meta-bug] ISO C binding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630 Bug 32630 depends on bug 40920, which changed state. Bug 40920 Summary: Derived type with BIND(C) - rejected as argument. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/42651] Functions with result: Wrongly accepts attributes to function name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42651
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-25
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
At revision 200371, I get the following errors:
pr42651.f90:17.19:
allocatable func2 ! { dg-error FUNCTION attribute conflicts with ALLOCATABL
1
Error: Function name 'func2' not allowed at (1)
pr42651.f90:18.14:
target func2 ! { dg-error FUNCTION attribute conflicts with TARGET }
1
Error: Function name 'func2' not allowed at (1)
pr42651.f90:19.17:
dimension func2(2) ! { dg-error FUNCTION attribute conflicts with DIMENSION
1
Error: Function name 'func2' not allowed at (1)
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear. Would not it be simpler to tell the users what they should do to avoid this issue? If yes, what would be the basic rules?
[Bug rtl-optimization/57706] New: LRA is bottleneck while compiling LTO firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57706 Bug ID: 57706 Summary: LRA is bottleneck while compiling LTO firefox Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org One of ltrans partitions wihle building firefox gets stuck with the following profile: CPU: AMD64 family10, speed 2100 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 75 samples %image name app name symbol name 8443227.1889 lto1 lto1 ggc_internal_alloc_stat(unsigned long) 5490 1.7679 libc-2.11.1.so libc-2.11.1.so _int_malloc 4746 1.5283 lto1 lto1 bitmap_set_bit(bitmap_head_def*, int) 4155 1.3380 libc-2.11.1.so libc-2.11.1.so memset 3190 1.0272 lto1 lto1 hash_table_mod1(unsigned int, unsigned int) 3029 0.9754 lto1 lto1 for_each_rtx_1(rtx_def*, int, int (*)(rtx_def**, void*), void*) 2860 0.9210 lto1 lto1 bitmap_bit_p(bitmap_head_def*, int) 2325 0.7487 lto1 lto1 df_note_compute(bitmap_head_def*) 2173 0.6998 as as hash_lookup 2102 0.6769 lto1 lto1 record_reg_classes(int, int, rtx_def**, machine_mode*, char const**, rtx_def*, reg_class*) 1859 0.5986 lto1 lto1 constrain_operands(int) 1804 0.5809 lto1 lto1 hash_tablevariable_hasher, xcallocator::find_slot_with_hash(void const*, unsigned int, insert_option) 1674 0.5391 libc-2.11.1.so libc-2.11.1.so malloc 1660 0.5346 lto1 lto1 operand_equal_p(tree_node const*, tree_node const*, unsigned int) 1653 0.5323 lto1 lto1 htab_find_slot_with_hash 1543 0.4969 libc-2.11.1.so libc-2.11.1.so _int_free 1538 0.4953 lto1 lto1 get_attr_enabled(rtx_def*) 1511 0.4866 lto1 lto1 mem_attrs_eq_p(mem_attrs const*, mem_attrs const*) 1376 0.4431 libc-2.11.1.so libc-2.11.1.so malloc_consolidate integrated RA : 57.28 (11%) usr 0.21 ( 3%) sys 57.51 (11%) wall 382450 kB (106%) ggc LRA non-specific: 5.35 ( 1%) usr 0.02 ( 0%) sys 5.43 ( 1%) wall 24447 kB ( 7%) ggc LRA virtuals elimination: 0.35 ( 0%) usr 0.01 ( 0%) sys 0.35 ( 0%) wall 8263 kB ( 2%) ggc LRA reload inheritance : 0.64 ( 0%) usr 0.01 ( 0%) sys 0.78 ( 0%) wall 11556 kB ( 3%) ggc LRA create live ranges : 1.11 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 2973 kB ( 1%) ggc LRA hard reg assignment : 166.89 (33%) usr 0.03 ( 0%) sys 166.96 (33%) wall 0 kB ( 0%) ggc LRA coalesce pseudo regs: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc reload : 0.13 ( 0%) usr 0.01 ( 0%) sys 0.18 ( 0%) wall 0 kB ( 0%) ggc reload CSE regs : 10.24 ( 2%) usr 0.04 ( 1%) sys 10.31 ( 2%) wall 51758 kB (14%) ggc load CSE after reload : 2.02 ( 0%) usr 0.01 ( 0%) sys 2.10 ( 0%) wall 185 kB ( 0%) ggc ree : 0.21 ( 0%) usr 0.02 ( 0%) sys 0.19 ( 0%) wall 696 kB ( 0%) ggc thread pro- epilogue : 0.78 ( 0%) usr 0.00 ( 0%) sys 0.76 ( 0%) wall 21050 kB ( 6%) ggc if-conversion 2 : 0.10 ( 0%) usr 0.02 ( 0%) sys 0.16 ( 0%) wall 214 kB ( 0%) ggc combine stack adjustments: 0.13 ( 0%) usr 0.02 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc peephole 2 : 0.77 ( 0%) usr 0.01 ( 0%) sys 0.70 ( 0%) wall 2982 kB ( 1%) ggc rename registers: 3.87 ( 1%) usr 0.00 ( 0%) sys 3.55 ( 1%) wall 16083 kB ( 4%) ggc hard reg cprop : 1.61 ( 0%) usr 0.01 ( 0%) sys 1.61 ( 0%) wall 821 kB ( 0%) ggc scheduling 2: 11.50 ( 2%) usr 0.03 ( 0%) sys 11.47 ( 2%) wall 15888 kB ( 4%) ggc machine dep reorg : 1.81 ( 0%) usr 0.01 ( 0%) sys 1.71 ( 0%) wall 590 kB ( 0%) ggc reorder blocks : 1.26 ( 0%) usr 0.03 ( 0%) sys 1.12 ( 0%) wall 15841 kB ( 4%) ggc shorten branches: 0.96 ( 0%) usr 0.00 ( 0%) sys 1.13 ( 0%) wall 0 kB ( 0%) ggc reg stack : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 69 kB ( 0%) ggc final : 6.98 ( 1%) usr 0.46 (
[Bug tree-optimization/57705] Non-constant step induction vars not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57705 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30358 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30358action=edit gcc49-pr57705.patch Patch I'm bootstrapping/regtesting right now.
[Bug tree-optimization/57698] rev.200179 causes many errors (inlining failures) when building Firefox
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698 --- Comment #3 from Jan Hubicka hubicka at ucw dot cz --- Hmm, the problem here is that we output errors after early inlining always now, while previously we did only when some other inlining happened in the function (adding extra early inlinable function to the testcase should reproduce the error message on early GCC releases). We can fix by outputting always inline errors only after real inliner was run (when optimizing) but then such testcases won't compile at -O0 that is uncol too. Other alternatives include declaring such testcases invalid, always not outputting diagnostic on previously indirect calls, teaching always inliner to do indirect inlining (that will need to do analysis at -O0), adding disregard_inline_limits attribute... Each of these has pros and cons...
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #29 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Martin Liška from comment #28) Patch solved the problem for chromium ;) I will test libreoffice tomorrow. Great, I have submitted the patch to the mailing list then: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01422.html
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #17 from Allan McRae allan at archlinux dot org --- Created attachment 30359 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30359action=edit gdb log when using -include When using -include instead of -imacros, the trail is: LC_ENTER foo.c LC_RENAME command-line LC_ENTER /usr/include/stdc-predef.h LC_LEAVE 0x0 LC_ENTER foo.h LC_LEAVE 0x0 LC_RENAME foo.c LC_LEAVE 0x0 gdb log with -include attached.
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de --- incredibly... gcc 4.3.7 was the last version that did only write 5 bytes in foo(). starting with gcc 4.4 all variants read/write 8 bytes in foo(). that applies only to the arm code. the x86 code does not use more than 5 bytes.
[Bug c/57707] New: gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707
Bug ID: 57707
Summary: gcc misinterprets hex escapes in constant strings
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: duncan_roe at acslink dot net.au
Created attachment 30360
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30360action=edit
Preprocessed program source (only has builtins)
This short self contained program
=
int write(int fd, const void *buf, int count);
int main(int argc, char **argv)
{
write(1, \x05CAT\n, 5);
//write(1, \x05 CAT\n, 5); // Works
write(1, \x05HAT\n, 5);
return 0;
} /* main(int argc, char **argv) */
=
should print:
control-E CAT
control-E HAT
But it prints:
Meta-JT
XX Control-E HAT
(with no spaces). Meta-J is 0XCA - the compiler has processed all legal hex
characters following 0x when it should have stopped after 2.
4.7.1 does issue a warning but I submit the warning is wrong - KR2 says on
page 38 that hex constants in strings are 0xhh.
Run through cat -A so you see the control characters:
=
21:35:03$ ./hexbug | cat -A
M-JT$
XX^EHAT$
=
This is gcc -v -save-temps ...
=
Script started on Tue 25 Jun 2013 09:33:06 PM EST
21:33:06$ gcc -v -save-temps -Wall -Wextra -g3 -ggdb 'hexbug.c' -o hexbug
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.7.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.7.1/lto-wrapper
Target: i486-slackware-linux
Configured with: ../gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix
--enable-checking=release --enable-objc-gc --with-system-zlib
--with-python-dir=/lib/python2.7/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose
--enable-java-home --with-java-home=/usr/lib/jvm/jre
--with-jvm-root-dir=/usr/lib/jvm --with-jvm-jar-dir=/usr/lib/jvm/jvm-exports
--with-arch-directory=i386
--with-antlr-jar=/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar
--enable-java-awt=gtk --disable-gtktest --with-arch=i486
--target=i486-slackware-linux --build=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 4.7.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-g3' '-ggdb' '-o'
'hexbug' '-mtune=i486' '-march=i486'
/usr/libexec/gcc/i486-slackware-linux/4.7.1/cc1 -E -quiet -v -dD hexbug.c
-mtune=i486 -march=i486 -Wall -Wextra -g3 -ggdb -fworking-directory
-fpch-preprocess -o hexbug.i
ignoring nonexistent directory
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i486-slackware-linux/4.7.1/include
/usr/local/include
/usr/lib/gcc/i486-slackware-linux/4.7.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-g3' '-ggdb' '-o'
'hexbug' '-mtune=i486' '-march=i486'
/usr/libexec/gcc/i486-slackware-linux/4.7.1/cc1 -fpreprocessed hexbug.i -quiet
-dumpbase hexbug.c -mtune=i486 -march=i486 -auxbase hexbug -g3 -ggdb -Wall
-Wextra -version -o hexbug.s
GNU C (GCC) version 4.7.1 (i486-slackware-linux)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.7.1 (i486-slackware-linux)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 147333b4f444708024f96128dde5
hexbug.c: In function 'main':
hexbug.c:8:12: warning: hex escape sequence out of range [enabled by default]
hexbug.c:6:14: warning: unused parameter 'argc' [-Wunused-parameter]
hexbug.c:6:27: warning: unused parameter 'argv' [-Wunused-parameter]
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-g3' '-ggdb' '-o'
'hexbug' '-mtune=i486' '-march=i486'
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/as
-v --32 -o hexbug.o hexbug.s
GNU assembler version 2.22.52.0.2 (i486-slackware-linux) using BFD version
(Linux/GNU Binutils) 2.22.52.0.2.20120424
COMPILER_PATH=/usr/libexec/gcc/i486-slackware-linux/4.7.1/:/usr/libexec/gcc/i486-slackware-linux/4.7.1/:/usr/libexec/gcc/i486-slackware-linux/:/usr/lib/gcc/i486-slackware-linux/4.7.1/:/usr/lib/gcc/i486-slackware-linux/:/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Hex escapes use the longest matching sequence.
[Bug target/57708] New: function clobbers callee saved register on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708 Bug ID: 57708 Summary: function clobbers callee saved register on ARM Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mikulas at artax dot karlin.mff.cuni.cz Compile the attached code with -O3 -mcpu=cortex-a15 -marm on ARM EABI (the bug happens with hardfp or without). The functions html_h3, html_h4, html_h5, html_h6 clobber the register r5 and do not save it. They save only r4. The bug is present in gcc-4.8 and gcc-4.8.1
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 --- Comment #2 from duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au --- I can see it is doing that. Where does the standard say that is correct behavior?
[Bug target/57708] function clobbers callee saved register on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708 mikulas at artax dot karlin.mff.cuni.cz changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz --- Created attachment 30361 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30361action=edit a code that reproduces the bug
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR fixed or not?
[Bug target/57708] function clobbers callee saved register on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708 --- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz --- Created attachment 30362 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30362action=edit another reproduction code The code in the first attachment actually did some out-of-memory accesses because I simplified it too much. This is the second attachment that should be correct.
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au --- (Should have changed the status last comment - sorry)
[Bug c++/57709] New: -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Bug ID: 57709
Summary: -Wshadow is too strict / has false positives
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-unknown-linux-gnu
class C {
int both_var;
void var_and_method() {}
void m() { int both_var, var_and_method; }
};
FAIL: gcc (GCC) 4.8.2 20130625 (prerelease)
FAIL: gcc (GCC) 4.9.0 20130625 (experimental)
g++ -c -o shadow.o shadow.C -Wshadow -Wno-unused
shadow.C:4:18: warning: declaration of ‘both_var’ shadows a member of 'this'
[-Wshadow]
shadow.C:4:28: warning: declaration of ‘var_and_method’ shadows a member of
'this' [-Wshadow]
clang-3.3-0.4.rc2.fc18.x86_64
clang -c -o shadow.o shadow.C -Wshadow -Wno-unused
shadow.C:4:18: warning: declaration shadows a field of 'C' [-Wshadow]
void m() { int both_var, var_and_method; }
^
shadow.C:2:7: note: previous declaration is here
int both_var;
^
1 warning generated.
--
clang does no warn on var_and_method as variable vs. method are safe, if one
tries to use them inappropriately one gets an error.
It is difficult to enable -Wshadow for existing project as it has many needless
warnings, with clang it is easier and still safe.
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- 6.4.4.4 Bugzilla is not the right place to learn C.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- clang does no warn on var_and_method as variable vs. method are safe, if one tries to use them inappropriately one gets an error. Not always. Think of function pointers or pointer to member functions. clang is not loose in my mind rather than GCC is too strict.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Yeah, I agree, this looks like a clang bug (or misdesigned feature) to me.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- It may not be exactly correct but from a practical standpoint clang has caught my bug while not annoying me with tons of needless changes like gcc did, FYI.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) clang does no warn on var_and_method as variable vs. method are safe, if one tries to use them inappropriately one gets an error. Not always. Think of function pointers or pointer to member functions. clang is not loose in my mind rather than GCC is too strict. In GCC 4.8 I implemented: The option -Wshadow no longer warns if a declaration shadows a function declaration, unless the former declares a function or pointer to function, because this is a common and valid case in real-world code. I think this is a useful heuristic also for member functions, no? I don't have time to work on this at the moment, but it would be useful to know whether the maintainers agree, so someone (Jan?) may start working on a patch.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) The option -Wshadow no longer warns if a declaration shadows a function declaration, unless the former declares a function or pointer to function, because this is a common and valid case in real-world code. I think this is a useful heuristic also for member functions, no? I don't have time to work on this at the moment, but it would be useful to know whether the maintainers agree, so someone (Jan?) may start working on a patch. That would be fine. But it seems less important for member functions, since there's much less chance of a local variable name conflicting with some random function declared by an #include file.
[Bug fortran/57710] New: [OOP] _vptr not set for allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710 Bug ID: 57710 Summary: [OOP] _vptr not set for allocatable CLASS components Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following code (minus the IF condition) shows that _vptr is not set for the allocatable component: y.x._data = 0B; there should be - but isn't - additionally: y.x._vptr = __vtab_m_T; Additionally, the test case as is (with IF condition), currently crashes with: internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1654 if (.not. same_type_as(y%x, z)) call abort () ^ 0x632ce2 gfc_conv_component_ref ../../gcc/fortran/trans-expr.c:1654 0x63fc89 gfc_conv_variable ../../gcc/fortran/trans-expr.c:1921 module m type t end type t type t2 integer :: ii class(t), allocatable :: x end type t2 contains subroutine fini(x) type(t) :: x end subroutine fini end module m use m block type(t) :: z type(t2) :: y y%ii = 123 if (.not. same_type_as(y%x, z)) call abort () end block end
[Bug fortran/57710] [OOP] _vptr not set for allocatable CLASS components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962#c20 Transformational intrinsics, done are: * all, any, count * product, sum * dot_product, matmul, transpose * pack, unpack, spread Left: * maxloc, minloc * maxval, minval (generic case) * cshift, eoshift While at it, see also PR29600 (kind arguments) and PR36313 (character type). Earlier this year, I was working on the cshift/eoshift, but I strongly believe that the linear list that builds the constructor must be replaced with splay trees before this can be implemented somewhat efficiently. I think what is left in pr29962 is a duplicate of this one.
[Bug fortran/29962] Initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- Closing as duplicate of pr45689. *** This bug has been marked as a duplicate of bug 45689 ***
[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 29962 has been marked as a duplicate of this bug. ***
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104 Bug 25104 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/31392] [meta-bug] gfortran problems with initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392 Bug 31392 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/31393] [meta-bug] gfortran compile-time problems with intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31393 Bug 31393 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32890 Bug 32890 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/37212] TRANSFER: Simplify array argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37212 Bug 37212 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205 Bug 38205 depends on bug 29962, which changed state. Bug 29962 Summary: Initialization expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/31392] [meta-bug] gfortran problems with initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392 Bug 31392 depends on bug 25104, which changed state. Bug 25104 Summary: [F2003] Non-initialization expr. as case-selector http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/45689] [F2003] Missing transformational intrinsic in the trans_func_f2003 list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 25104 has been marked as a duplicate of this bug. ***
[Bug fortran/20585] [meta-bug] Fortran 2003 support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 25104, which changed state. Bug 25104 Summary: [F2003] Non-initialization expr. as case-selector http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr45689. *** This bug has been marked as a duplicate of bug 45689 ***
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- However, one should go through the lengthy, convoluted thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ to check whether it contains some still-unfixed issues. The thread is too convoluted for me. Is this still an issue?
[Bug fortran/57711] New: Fortran 4.7.2/4.8.1 error: constraints for functions parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 Bug ID: 57711 Summary: Fortran 4.7.2/4.8.1 error: constraints for functions parameters Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kabanovdmitry at gmail dot com I try to compile the fortran program which my advisor gave me. It doesn't want to compile when I'm doing this with gfortran 4.7.2 on Mac OS X 10.8.4 and with gfortran 4.8.1 on Arch Linux x64. I've built the minimal working example which replays the error. Unfortunately, it's quite big anyway, so I've put it on the github: https://github.com/kabanovdmitry/vode-test I can compile this code under Ubuntu 12.04 with gfortran 4.6.3. I've checked press releases for GCC 4.7 and found nothing that could give me a clue. Seems like gfortran's rules for functions parameters became stricter without an announcement.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Thanks!
I think I know the reason why it is failing, but I am not sure about the proper
fix.
For some reason unknown to me, push_commandline_include should not be called
while processing -imacros. -imacros tries to achieve this but playing tricks
with include_cursor, but that doesn't stop the pre-included files. Calling
cpp_push_include (or cpp_push_default_include) seems to mess up everything
(again, no idea why!). This code is really a mess but the simple patch below
seems to work. Could you test it?
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c (revision 200330)
+++ gcc/c-family/c-opts.c (working copy)
@@ -1338,10 +1338,14 @@ c_finish_options (void)
/* Give CPP the next file given by -include, if any. */
static void
push_command_line_include (void)
{
+ // This can happen if disabled by -imacros for example.
+ if (include_cursor deferred_count)
+return;
+
if (!done_preinclude)
{
done_preinclude = true;
if (flag_hosted std_inc !cpp_opts-preprocessed)
{
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- As for 4.8.1 and trunk (r200371), only the second test in comment #0 gives the 'ppr@' name: real g ! cannot have a type 1 Error: Symbol 'ppr@' at (1) cannot have a type The first test does not give any error and the third one gives (once) integer function h(x) ! is missing the pointer attribute (twice!) 1 Error: Procedure pointer result 'h' at (1) is missing the pointer attribute The error for the test in comment #1 is p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mismatch in function result for 4.8.1 and p = f() ! Invalid f() returns a LOGICAL(1) function, but p is a REAL one 1 Error: Interface mismatch in procedure pointer assignment at (1): Type mismatch in function result (REAL(4)/LOGICAL(1)) for the trunk.
[Bug c++/57712] New: GCC fails to to match out-of-line template member function definition with declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57712
Bug ID: 57712
Summary: GCC fails to to match out-of-line template member
function definition with declaration
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: st at quanttec dot com
g++ 4.8.1 fails to compile the following C++11 code:
struct Test {
int method(int value) { return value; }
template typename T
auto test(T value) - decltype(this-method(value));
};
template typename T
auto Test::test(T value) - decltype(this-method(value)) {
return this-method(value);
}
int main() {
Test t;
return t.test(0);
}
g++ --std=c++11 test.cpp
test.cpp:9:6: error: prototype for ‘decltype (this-.Test::method(value))
Test::test(T)’ does not match any in class ‘Test’
auto Test::test(T value) - decltype(this-method(value)) {
^
test.cpp:5:8: error: candidate is: templateclass T decltype
(this-.Test::method(value)) Test::test(T)
auto test(T value) - decltype(this-method(value));
If the member function is defined inline, gcc compiles it fine.
[Bug c++/57709] -Wshadow is too strict / has false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jason Merrill from comment #5) That would be fine. But it seems less important for member functions, since there's much less chance of a local variable name conflicting with some random function declared by an #include file. Well, Jan here is complaining precisely that a local variable (not function pointer, not other function) conflicts with a member function. I would expect that to almost never happen but I guess some programmers are not very good at naming things ;-)
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #43 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment #39, it seems that this PR could be closed as FIXED.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #16 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #15) However, the fundamental(?) issue of module sizes growing exponentially with deep module hierarchies still remains. The solution to that is to not include transitive dependencies, which in turn would require a module cache for good performance. Whether that is worth doing, and who is willing and able to do it, is unclear. Would not it be simpler to tell the users what they should do to avoid this issue? If yes, what would be the basic rules? I doubt that this is the right answer. The user wants to write maintainable and portable code. The paradigm of object-oriented programming will more often lead to deeper module hierarchies than simple code. You'd had a hard time to tell users that gfortran requires to flatten those hierarchies when other compilers don't (assuming that the others perform acceptably).
[Bug c++/57713] New: Template functions see friendship as inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57713
Bug ID: 57713
Summary: Template functions see friendship as inherited
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w.shane.grant at gmail dot com
Template functions that are friends of a class bypass access control for
derived classes.
--
template class T T declval();
template class T
auto foo() - decltype(declvalT().bar()) {}
class Base
{
private:
template class T
friend auto foo() - decltype(declvalT().bar());
void bar(){}
};
class Derived : public Base {};
int main()
{
fooDerived();
}
---
bar should be private in Derived but the friend declaration in Base is allowing
foo to access it, preventing compilation from failing. Here's another very
similar example:
-
template class T
void foo(Tt)
{
t.bar();
}
class Base
{
private:
template class T
friend void foo(T);
void bar(){}
};
class Derived : public Base {};
int main()
{
foo(Derived());
}
Derived gets the ability to call bar() only inside of the template function
foo.
Happens on (4.9.0 20130625 (experimental)) and (4.8.1).
[Bug fortran/51535] Optimization problem with -finit-real=snan at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535 --- Comment #3 from Harald Anlauf anlauf at gmx dot de --- (In reply to Dominique d'Humieres from comment #2) I can reproduce it with gfortran 4.7.3 and '-O2 -ffpe-trap=zero,overflow,invalid -finit-real=snan -mfpmath=387', but not with 4.8.1 nor trunk. Could this PR be closed as FIXED? As the status accidentally fixed in 4.8 but do not know when and why does not exist, you may well do that.
[Bug fortran/42607] add information about how to compile a module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #13 from Harald Anlauf anlauf at gmx dot de --- Since Cray was mentioned, the Cray online documentation says: [...] The following files are produced by or accepted by the Cray Fortran compiler: [...] modulename.mod If the -em option is specified, the compiler writes a modulename.mod file for each module; modulename is created by taking the name of the module and, if necessary, converting it to uppercase. This file contains module information, including any contained module procedures. I consider that an example of a reasonable documentation. Gfortran generated module files (modulename.mod) are always lower case. Gfortran creates a .mod file not only for -c, but also for -fsyntax-only, and apparently always when it is presented a source file which contains a module statement. It should not be that difficult to put that into the documentation.
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779
Dâniel Fraga fragabr at gmail dot com changed:
What|Removed |Added
CC||fragabr at gmail dot com
--- Comment #3 from Dâniel Fraga fragabr at gmail dot com ---
Is this already fixed? I installed gcc 4.8.2 20130620 (prerelease) and it keeps
happening. For example, when trying to configure Firefox:
configure:3223: checking whether the C++ compiler (c++ -march=native -O3 -pipe
-floop-interchange -floop-strip-mine -floop-block -L/usr/local/ssl/lib
-L/usr/local/BerkeleyDB/lib -L/usr/X11/lib -L/usr/local/lib64) works
configure:3239: c++ -o conftest -march=native -O3 -pipe -floop-interchange
-floop-strip-mine -floop-block -L/usr/local/ssl/lib
-L/usr/local/BerkeleyDB/lib -L/usr/X11/lib -L/usr/local/lib64 conftest.C 15
/usr/local/lib64/libstdc++.so: undefined reference to `libintl_gettext'
/usr/local/lib64/libstdc++.so: undefined reference to `libintl_textdomain'
/usr/local/lib64/libstdc++.so: undefined reference to `libintl_bindtextdomain'
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 3234 configure
#include confdefs.h
int main(){return(0);}
*
It started to happen with gcc 4.8.0. So something was changed in 4.8.0 to cause
this.
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #7 from Vittorio Zecca zeccav at gmail dot com --- It looks like it was fixed in 4.7.0 with the following error message Error: NULL intrinsic at (1) in data transfer statement requires MOLD=
[Bug fortran/51535] Optimization problem with -finit-real=snan at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- As the status accidentally fixed in 4.8 but do not know when and why does not exist, you may well do that. I get the SIGFPE with revision 192891 (2012-10-28) and 'In p_h_usstd!' with revision 193261 (2012-11-06) and newer. Note that since the SIGFPE needs -O1, it may have been fixed in the middle-end. But if you really want to find out, you'll have to do the remaining bisection yourself. BTW in comment #2 I ment '-O1 -ffpe-trap=zero,overflow,invalid -finit-real=snan -mfpmath=387'.
[Bug fortran/51535] Optimization problem with -finit-real=snan at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51535 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from Harald Anlauf anlauf at gmx dot de --- Apparently gone between revision 192891 and revision 193261 (see comment #4)
[Bug c++/57713] Template functions see friendship as inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57713
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Shane w.shane.grant at gmail dot com ---
Marking invalid since I think this was actually a case of not interpreting
friendship correctly. A simpler test case:
class Base {
private:
friend void foo();
void bar();
};
class Derived : public Base {};
void foo() { Derived().bar(); }
also compiles with no error because has access to Base (due to friendship) and
thus access to bar.
[Bug preprocessor/57714] New: Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Bug ID: 57714
Summary: Newline rendered incorrectly in output
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
main(){\
return 0;
}
preprocesses to
main(){return
0;
}
The problem only appears in output from the -E option; observing the newline
within the program as with
#define main(){\
return 0;
}
main()
produces the correct result
}
{return 0;
This is a regression since 4.2.1; the GCC version included with Mac OS X does
not exhibit the problem.
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is correct behavior for the continuing of the line.
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714 --- Comment #2 from David Krauss potswa at mac dot com --- Andrew, are you sure? The zero should remain on the same line as the return token.
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714 --- Comment #3 from David Krauss potswa at mac dot com --- See section 9 of the manual: http://gcc.gnu.org/onlinedocs/gcc-4.8.1/cpp/Preprocessor-Output.html#Preprocessor-Output The output from the C preprocessor looks much like the input, except that all preprocessing directive lines have been replaced with blank lines and all comments with spaces. Long runs of blank lines are discarded. ... CPP does not insert any whitespace where there was none in the original source, except where necessary to prevent an accidental token paste.
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 --- Comment #6 from Steve Ellcey sje at gcc dot gnu.org --- The patch in comment #3 worked for me as well.
[Bug testsuite/57687] FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #4 from Steve Ellcey sje at gcc dot gnu.org --- I am seeing this failure on the mips-mti-elf target. Since gather_scatter.c can be fixed with a testsuite change, I think it is seperate from this failure. From the log file: Executing on host: /scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/gcc/testsuite/g++/../../xg++ -B/scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/gcc/testsuite/g++/../../ /scratch/gcc/nightly/src/gcc/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c -fno-diagnostics-show-caret -fdiagnostics-color=never --sysroot=/scratch/gcc/nightly/install-mips-mti-elf/mips-mti-elf -nostdinc++ -I/scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/mips-mti-elf/libstdc++-v3/include/mips-mti-elf -I/scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/mips-mti-elf/libstdc++-v3/include -I/scratch/gcc/nightly/src/gcc/libstdc++-v3/libsupc++ -I/scratch/gcc/nightly/src/gcc/libstdc++-v3/include/backward -I/scratch/gcc/nightly/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -fcilkplus -fcilkplus -L/scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/mips-mti-elf/./libstdc++-v3/src/.libs -B/scratch/gcc/nightly/obj-mips-mti-elf/gcc/final/mips-mti-elf/./libstdc++-v3/src/.libs -lm -Tmti32.ld -o ./comma_exp.exe(timeout = 300) In function 'int main2(char**)':^M cc1plus: error: 'anonymous' has incomplete type^M /scratch/gcc/nightly/src/gcc/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void'^M cc1plus: error: cc1plus: error: 'anonymous' has incomplete type^M /scratch/gcc/nightly/src/gcc/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void'^M compiler exited with status 1 output is: In function 'int main2(char**)':^M cc1plus: error: 'anonymous' has incomplete type^M /scratch/gcc/nightly/src/gcc/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void'^M cc1plus: error: 'anonymous' has incomplete type^M /scratch/gcc/nightly/src/gcc/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void'^M'anonymous' has incomplete type^M
[Bug lto/57715] New: lto1.exe: internal compiler error: in add_symbol_to_partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57715 Bug ID: 57715 Summary: lto1.exe: internal compiler error: in add_symbol_to_partition Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: linuxsquirrel.dev at gmail dot com Using MinGW-builds, 4.8.1 version. I try to compile Qt 4.8.4 with -flto on Windows 7 32-bit: jom ... g++ -c -include tmp\obj\release_shared\qt_gui_pch.h -pipe -fno-keep-inline-dllexport -flto -O2 -Wall -Wextra -frtti -fexceptions -mthreads -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE-DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_NO_DIRECTDRAW -DQT_USE_BUNDLED_LIBPNG -DPNG_NO_ASSEMBLER_CODE -DQT_NO_CUPS -DQT_NO_LPR -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQT_NO_EGL -DQ_INTERNAL_QAPP_SRC -DQT_NO_DIRECTWRITE -DQT_DLL -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I..\..\include\QtCore -I..\..\include -I..\..\extra\openssl\include -I..\..\include\QtGui -Itmp\rcc\release_shared -Itmp -I..\3rdparty\wintab -Iimage -I..\3rdparty\libpng -I..\3rdparty\zlib -I..\3rdparty\zlib -I..\3rdparty\harfbuzz\src -Idialogs -I..\..\include\ActiveQt -Itmp\moc\release_shared -I. -I..\..\mkspecs\win32-g++-4.6 -o tmp\obj\release_shared\qlistwidget.o itemviews\qlistwidget.cpp g++ -flto -Wl,-s -mthreads -shared -Wl,--out-implib,f:\qt4-tht-toolchain\lib\libQtGui4.a -o ..\..\lib\QtGui4.dll object_script.QtGui.Release -Lf:\qt4-tht-toolchain\lib -Lf:\qt4-tht-toolchain\lib -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lws2_32 -lole32 -luuid -luser32 -ladvapi32 tmp\obj\release_shared\QtGui_resource_res.o -LF:\qt4-tht-toolchain\extra\openssl\lib -LF:\qt4-tht-toolchain\extra\openssl\bin -lmsimg32 -lshell32 -lQtCore4 lto1.exe: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Please submit a full bug report, with preprocessed source if appropriate. See http://sourceforge.net/projects/mingwbuilds/ for instructions. lto-wrapper: g++ returned 1 exit status f:/qt4-tht-toolchain/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.1/../../../../i686-w64 -mingw32/bin/ld.exe: lto-wrapper failed collect2.exe: error: ld returned 1 exit status --- gcc -v Using built-in specs. COLLECT_GCC=F:\dev\Qt4-THT-toolchain\mingw\bin\gcc.EXE COLLECT_LTO_WRAPPER=f:/dev/qt4-tht-toolchain/mingw/bin/../libexec/gcc/i686-w64-mingw3 2/4.8.1/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.8.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/tmp/x32-481-posix-sjlj-r1/mingw32 --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-host-libstdcxx='-static -lstdc++' --with-libiconv --with-system-zlib --with-gmp=/tmp/mingw-prereq/i686-w64-mingw32-static --with-mpfr=/tmp/mingw-prereq/i686-w64-mingw32-static --with-mpc=/tmp/mingw-prereq/i686-w64-mingw32-static --with-isl=/tmp/mingw-prereq/i686-w64-mingw32-static --with-cloog=/tmp/mingw-prereq/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='rev1, Built by MinGW-builds project' --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS='-O2 -pipe -I/tmp/x32-481-posix-sjlj-r1/libs/include -I/tmp/mingw-prereq/x32-zlib/include -I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/tmp/x32-481-posix-sjlj-r1/libs/include -I/tmp/mingw-prereq/x32-zlib/include -I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/tmp/x32-481-posix-sjlj-r1/libs/lib -L/tmp/mingw-prereq/x32-zlib/lib -L/tmp/mingw-prereq/i686-w64-mingw32-static/lib -L/tmp/x32-481-posix-sjlj-r1/mingw32/opt/lib' Thread model: posix gcc version 4.8.1 (rev1, Built by MinGW-builds project)
[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55587 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- This patch is broken for testing the already installed GCC.
[Bug fortran/57711] Fortran 4.7.2/4.8.1 error: constraints for functions parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- (1) What error(s) do you get? (2) Are you sure that you can compile the code you have posted with 4.6.3? (3) could you further reduce vode.f?
[Bug testsuite/57687] FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin10 |x86_64-apple-darwin10 ||mips-mti-elf Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-25 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment #4, confirmed.
[Bug libstdc++/57716] New: std::thread does not compile with vectorint as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716
Bug ID: 57716
Summary: std::thread does not compile with vectorint as
argument
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
When trying out the std::thread support in g++ 4.8.1, I tried this test
program:
#include thread
#include vector
using namespace std;
void thethread(vectorint b) {
// do something
}
int main() {
vectorint x { 1,2,3 };
thethread(x); // works
thread foo(thethread,x); // compiler error
foo.join();
}
calling the thread directly works, but doing it via the thread initialization
fails with this error message:
In file included from /usr/include/c++/4.8.1/thread:39:0,
from t.cc:1:
/usr/include/c++/4.8.1/functional: In instantiation of ‘struct
std::_Bind_simplevoid (*(std::vectorint))(std::vectorint)’:
/usr/include/c++/4.8.1/thread:137:47: required from
‘std::thread::thread(_Callable, _Args ...) [with _Callable = void
()(std::vectorint); _Args = {std::vectorint, std::allocatorint }]’
t.cc:13:25: required from here
/usr/include/c++/4.8.1/functional:1697:61: error: no type named ‘type’ in
‘class std::result_ofvoid (*(std::vectorint))(std::vectorint)’
typedef typename result_of_Callable(_Args...)::type result_type;
^
/usr/include/c++/4.8.1/functional:1727:9: error: no type named ‘type’ in ‘class
std::result_ofvoid (*(std::vectorint))(std::vectorint)’
_M_invoke(_Index_tuple_Indices...)
^
I also tried 4.8.0, same issue. A fried tried this with g++ 4.6.3 and it
worked there, so it appears to be a regression. Or maybe Ubuntu fixed
something in their branch of g++. I'm using stock gcc, the friend tried the
gcc from Ubuntu 12.04.
Note that the issue goes away if I change the function to take a pointer
instead of a reference to a vectorint.
[Bug libstdc++/57716] std::thread does not compile with vectorint as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57716 felix-gcc at fefe dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from felix-gcc at fefe dot de --- Never mind, this appears to be by design. http://stackoverflow.com/questions/15235885/invalid-initialization-of-non-const-reference-with-c11-thread
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Krauss from comment #0)
main(){\
return 0;
}
preprocesses to
main(){return
0;
}
Actually, according to: http://gcc.gnu.org/wiki/FAQ#cpp_continuation_discarded
I am surprised the backslash is not simply discarded. It is discarded if you
add a space before the return. It is a bug that it is NOT discarded,
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au --- There's no need for that. C is defined in Kernighan Ritchie's The C Programming Language. They mandate \xhh as a character escape. No mention of except when the next character happens to be a hex digit.
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from duncan_roe at acslink dot net.au duncan_roe at acslink dot net.au --- Will look for 6.4.4.4. And try a non-gnu compiler. In the meantime I'll take your word for it
[Bug c/57707] gcc misinterprets hex escapes in constant strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57707 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to duncan_...@acslink.net.au from comment #5) There's no need for that. C is defined in Kernighan Ritchie's The C Programming Language. They mandate \xhh as a character escape. No mention of except when the next character happens to be a hex digit. No it is not defined there. It is defined by the ISO C standard. The section 6.4.4.4 is where this specific item is defined.
