http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58024
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461
Joost VandeVondele changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58024
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #8 from Tobias Burnus ---
(In reply to H.J. Lu from comment #7)
> Can you add "-funroll-loops --param max-unroll-times=7"?
On Intel Core i5-3570 (glibc-2.18, openSUSE 13.1b1), I get with the attached
Intel .s file and today's GCC:
re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #15 from Tobias Burnus ---
(In reply to Bill Long from comment #14)
> Just a note that I'm now using
> GNU Fortran (MacPorts gcc49 4.9-20130609_0) 4.9.0 20130609 (experimental)
> and the original test case works with this version.
Tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58541
Bug ID: 58541
Summary: [c++11] Bogus "error: redeclaration ... differs in
‘constexpr’"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58540
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58539
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58540
Bug ID: 58540
Summary: Incorrect warning message for '*=' statement and
different results based on optimization
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #14 from Bill Long ---
Just a note that I'm now using
$ gf --version
GNU Fortran (MacPorts gcc49 4.9-20130609_0) 4.9.0 20130609 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
and the original test case works with th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001
Joshua Cogliati changed:
What|Removed |Added
Attachment #30873|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58513
--- Comment #3 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Sep 26 01:36:49 2013
New Revision: 202932
URL: http://gcc.gnu.org/viewcvs?rev=202932&root=gcc&view=rev
Log:
2013-09-24 Cong Hou
Backport from mainline:
2013-09-24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #9 from congh at gcc dot gnu.org ---
Author: congh
Date: Thu Sep 26 01:36:49 2013
New Revision: 202932
URL: http://gcc.gnu.org/viewcvs?rev=202932&root=gcc&view=rev
Log:
2013-09-24 Cong Hou
Backport from mainline:
2013-09-24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
john.harper at vuw dot ac.nz changed:
What|Removed |Added
CC||john.harper at vuw dot ac.nz
/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-checking=release
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130925 (experimental
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58538
Bug ID: 58538
Summary: Injected class-name treated as type-name instead of
template-name when used as a template-argument for a
template template-parameter
Product: gcc
x=/home/craig/new-gcc/i-4.8
Thread model: posix
gcc version 4.8.2 20130925 (prerelease) (GCC)
I get similar results with this version:
Using built-in specs.
COLLECT_GCC=/home/craig/new-gcc/i-trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-trunk/libexec/gcc/x86_64-unknown-linux-gnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58536
Bug ID: 58536
Summary: [c++1y] ICE with auto in constructor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58535
Bug ID: 58535
Summary: [4.8/4.9 Regression] ICE with virtual template
function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58534
Bug ID: 58534
Summary: [c++1y] ICE with auto in template function parameters
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58533
Bug ID: 58533
Summary: [c++1y] ICE with auto in function pointer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
--- Comment #9 from Marc Glisse ---
Author: glisse
Date: Wed Sep 25 20:28:12 2013
New Revision: 202924
URL: http://gcc.gnu.org/viewcvs?rev=202924&root=gcc&view=rev
Log:
2013-09-25 Marc Glisse
PR libstdc++/58338
* include/bits/forward_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58461
--- Comment #3 from Matthew Fortune ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> I think it'd be wrong for the backend to say that moves between
> MIPS16 registers and other general registers are more expensive
> than memory though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #7 from H.J. Lu ---
Can you add "-funroll-loops --param max-unroll-times=7"?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58436
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58436
--- Comment #3 from Tobias Burnus ---
Author: burnus
Date: Wed Sep 25 19:56:20 2013
New Revision: 202923
URL: http://gcc.gnu.org/viewcvs?rev=202923&root=gcc&view=rev
Log:
2013-09-25 Tobias Burnus
PR fortran/58436
* class.c (ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697
--- Comment #15 from Tobias Burnus ---
Author: burnus
Date: Wed Sep 25 19:54:12 2013
New Revision: 202922
URL: http://gcc.gnu.org/viewcvs?rev=202922&root=gcc&view=rev
Log:
2013-09-25 Tobias Burnus
PR fortran/57697
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58469
--- Comment #3 from Tobias Burnus ---
Author: burnus
Date: Wed Sep 25 19:54:12 2013
New Revision: 202922
URL: http://gcc.gnu.org/viewcvs?rev=202922&root=gcc&view=rev
Log:
2013-09-25 Tobias Burnus
PR fortran/57697
PR fortran/58
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #6 from Marc Glisse ---
Please ignore my last comment, I now see the same 30% difference, the rest must
have been a user error on my part.
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
I just tried to bootstrap gcc 4.9 trunk dated
20130925 on an AMD Phenom with BOOT_CFLAGS="-g -O3".
It failed, but on checking the difference between
-O2 and -O3, I got the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58530
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
--- Comment #2 from Charles ---
Hi,
I think I got this right. Found a file in /tmp that had stuff like this:
CMakeFiles/Fix_Engine_Detail_ut.dir/Message_Index_ut.cpp.o
CMakeFiles/Fix_Engine_Detail_ut.dir/Message_Log_ut.cpp.o
CMakeFiles/Fix_Engin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #18 from Rick Regan ---
(In reply to Vincent Lefèvre from comment #17)
> I confirm that it is an architecture-dependent bug. I can't reproduce any
> error with your test program on
> http://www.exploringbinary.com/incorrectly-rounded-c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #5 from Marc Glisse ---
I actually see gcc 4 times (not just 30%) slower than icpc here using the same
command lines. The asm produced by gcc contains tons of mov insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58531
--- Comment #4 from Guillaume ---
Ok i understand.
I took a sad brain shortcut assuming a single block declaration was generating
an (only possible) increasing address for each compound.
This was working on all previous gcc version i used (as far
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58531
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58531
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58531
--- Comment #1 from Guillaume ---
Created attachment 30897
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30897&action=edit
test.c / Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58531
Bug ID: 58531
Summary: [4.7/4.8 Regression] Strange array element ordering
with O1 flag
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #17 from Vincent Lefèvre ---
I confirm that it is an architecture-dependent bug. I can't reproduce any error
with your test program on
http://www.exploringbinary.com/incorrectly-rounded-conversions-in-gcc-and-glibc/
even with old gcc v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #4 from Tobias Burnus ---
(In reply to Marc Glisse from comment #3)
> Does it help if you pass the_bins_size as int*restrict (and adapt the uses)?
> Or use a local variable instead that you write at the end?
That doesn't have any effe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Comment #16 from Rick Regan ---
I can no longer find any conversions that gcc (I'm using 4.6.3) performs
incorrectly, including the examples cited above. It doesn't look like there has
been any related code changes in real.c though. Is this an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58530
Marek Polacek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58530
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #3 from Marc Glisse ---
Does it help if you pass the_bins_size as int*restrict (and adapt the uses)? Or
use a local variable instead that you write at the end? Gcc has a notoriously
restricted view of what restrict means, compared to m
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 30896
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30896&action=edit
gzipped C++ source code
I just tried to compile package activemq-cpp-3.7.1-1 with gcc 4.9 trunk
dated 20130925.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #2 from Tobias Burnus ---
Created attachment 30895
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30895&action=edit
Assembler generated by Intel's icpc for test.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
--- Comment #1 from Tobias Burnus ---
Created attachment 30894
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30894&action=edit
Main file (calls test file in a loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58529
Bug ID: 58529
Summary: Loop 30% faster with Intel than with GCC
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot net
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
--- Comment #1 from Richard Biener ---
Please try to reduce the testcase, see
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #3 from Marc Glisse ---
(In reply to Nick Maclaren from comment #2)
> I would be interested in a reference to the wording in the standard,
> if you know it offhand. I failed to find it.
[temp.deduct.call]
For a function parameter pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #2 from Nick Maclaren ---
Thanks. I can't use your fix, because I am trying to write a generic
multi-dimensional array class for possible inclusion in the standard,
and demanding such usages from end users is Not On. There are other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
--- Comment #1 from Marc Glisse ---
The parameter pack can only be deduced if it is in last position (that's an
arbitrary restriction, but it is in C++11). However, you can still do:
weeble(123,456,789,3.1416);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
Bug ID: 58528
Summary: lto1: internal compiler error: in build_abbrev_table,
at dwarf2out.c:7478
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58527
Bug ID: 58527
Summary: Failures when a function parameter pack is not final
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
--- Comment #4 from Malcolm Inglis ---
I don't have a copy of the C99 standard, but IBM says [1] that if the function
is called with a pointer to a smaller array than specified with `static`, then
the behavior is undefined. Ergo, there should be a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58526
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58513
Bug 58513 depends on bug 58521, which changed state.
Bug 58521 Summary: [4.9 Regression] bootstrap failure: ICE in mem_ref_in_stmt,
at tree-ssa-loop-im.c:677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Blocks|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Wed Sep 25 09:51:13 2013
New Revision: 202889
URL: http://gcc.gnu.org/viewcvs?rev=202889&root=gcc&view=rev
Log:
2013-09-25 Richard Biener
PR middle-end/58521
* tree.c (itera
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58510
--- Comment #3 from Marek Polacek ---
At first blush this seems to fix it:
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -980,9 +980,12 @@ sort_mem_initializers (tree t, tree mem_inits)
else if (TREE_VALUE (*last_p) && !TREE_VALUE (ini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58510
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Wed Sep 25 09:04:20 2013
New Revision: 202887
URL: http://gcc.gnu.org/viewcvs?rev=202887&root=gcc&view=rev
Log:
PR sanitizer/58420
* ubsan.c (ubsan_type_descriptor): Handle IDEN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Wed Sep 25 08:58:57 2013
New Revision: 202886
URL: http://gcc.gnu.org/viewcvs?rev=202886&root=gcc&view=rev
Log:
PR sanitizer/58413
c-family/
* c-ubsan.c (ubsan_instrument_shift)
On 09/24/2013 05:53 PM, rearnsha at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58490
>
> --- Comment #2 from Richard Earnshaw ---
> Can you let me know whether
>
> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00553.html
>
> fixes the problem?
This remind me an issue I r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58526
Bug ID: 58526
Summary: Inlining looses restrict qualifier and leads to loop
versioned vectorization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: mis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #6 from Richard Biener ---
Btw, the ICE hints at iterative_hash_expr and operand_equal_p being out-of-sync
after the change. Yep:
/* The type of the second operand is relevant, except for
its top-level qualifiers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58516
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #5 from Andreas Schwab ---
spawn /usr/local/gcc/gcc-20130925/Build/./gcc/xg++ -shared-libgcc
-B/usr/local/gcc/gcc-20130925/Build/./gcc -nostdinc++
-L/usr/local/gcc/gcc-20130925/Build/ia64-suse-linux/libstdc++-v3/src
-L/usr/local/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58516
--- Comment #5 from Marek Polacek ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58516
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Wed Sep 25 07:48:47 2013
New Revision: 202883
URL: http://gcc.gnu.org/viewcvs?rev=202883&root=gcc&view=rev
Log:
PR c++/58516
cp/
* semantics.c (finish_transaction_stmt): Check f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525
--- Comment #1 from Alexander Ivchenko ---
Created attachment 30891
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30891&action=edit
Proposed untested fix
Proposed untested fix is attached
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58525
Bug ID: 58525
Summary: __cxa_throw_bad_array_new_length is generated with
-fno-exceptions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58521
--- Comment #3 from Tobias Burnus ---
As remarked in PR58524: For me, it failed with MALLOC_PERTURB_ set and didn't
without, which implies that some uninitialized memory is used.
79 matches
Mail list logo
