Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Target Milestone: ---
The testsuite/24_iterators/random_access/string_vector_iterators.cc test
contains the following code blob
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Target Milestone: ---
In cleaning up some old internal bugs, I came across this one from years ago
when I was running the 4.9.4
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Target Milestone: ---
This problem showed up when we were running the GCC 4.9.4 testsuite with the
latest Clang trunk as the compiler, and found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
--- Comment #7 from Brooks Moses ---
Thanks, Jonathan! I've confirmed that this does indeed fix the warning with
Clang trunk, and the test passes again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91871
--- Comment #1 from Brooks Moses ---
FWIW, this function only seems to be used in the seven
testsuite/23_containers/*/14340.cc tests.
: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Target Milestone: ---
I have been running the libstdc++ testsuite with LLVM, and a recent change in
LLVM's warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #6 from Brooks Moses ---
(In reply to Eric Gallager from comment #5)
> Is that patch still relevant?
The relevant part of the libssp configure.ac hasn't changed much (if at all)
since I posted the patch, so I think it's still worth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125
Brooks Moses changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
---
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Target Milestone: ---
We've been working on getting libstdc++ to link correctly with LLD, and came
across a problematic dupli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #7 from Brooks Moses ---
Right, understood, but Roland seemed pretty insistent in the discussion on bug
57740 that this was a libstdc++ bug, not a glibc bug. Your contention is that
this is invalid because he's wrong about that, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #12 from Brooks Moses brooks at gcc dot gnu.org ---
Thanks, Richard! It looks like I'll need to backport this to our
google/gcc-4_9 branch before that happens; any chance you already have a
version of this patch that works with 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #13 from Brooks Moses brooks at gcc dot gnu.org ---
FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with.
I'm not sure it's optimal, but it seems to work.
Index: gcc/tree-data-ref.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Consider the following reduced testcase:
template typename T, typename = decltype(*static_castT*(0) = 0) int
break_it();
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
--- Comment #4 from Brooks Moses brooks at gcc dot gnu.org ---
Thanks. I have to admit that that does seem more generally useful! :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
--- Comment #2 from Brooks Moses brooks at gcc dot gnu.org ---
Ping? Any updates on this?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
GCC should warn about obvious bugs in binding a reference to temporary.
Small test case:
struct Foo {
Foo(int x): x_(x) { }
int x_;
};
int main
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Created attachment 33328
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33328action=edit
(Example program)
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
--- Comment #8 from Brooks Moses brooks at gcc dot gnu.org ---
Here's the traceback:
$ ~/gcc-archive/trunk/213772/bin/g++ --std=c++11 -c t2.cc
t.cc: In instantiation of ‘std::function_Res(_ArgTypes
...)::function(_Functor) [with _Functor = C
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Created attachment 33316
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33316action=edit
Small example program.
(Google ref: b/17007254)
The following program
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Consider the following code:
--cut here-
typedef unsigned int uint32;
template uint32 offset
int foo(uint32 x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
--- Comment #15 from Brooks Moses brooks at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
[...]
* g++.dg/cpp0x/initlist86.C (main): Initialize i.
[...]
Aha ... yes, that would do it. And, indeed, I can confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
--- Comment #11 from Brooks Moses brooks at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #10)
Thanks. Does removing PUSH_ARGS_REVERSED from the cp_gimplify_expr
change fix it?
Nope -- I just gave it a try, and it doesn't seem
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
Google ref: b/15984570
This source:
/// --- cut ---
struct Outer {
void Bar();
struct Foo {
void (Outer::*ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #8 from Brooks Moses brooks at gcc dot gnu.org ---
Yup, that's essentially exactly what I had in mind, with a couple of minor
adjustments:
* I'd use your original patch of -fabi-version=0 to altivec-7.C, so that we're
continuing
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
We've run into a GCC miscompile problem with KR-style function definitions
that's causing some various old GNU software to fail in some cases.
A simple test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #4 from Brooks Moses brooks at gcc dot gnu.org ---
Interesting. As noted, with -fabi-version=[1 to 3] on Linux, I was getting
both sets.
Mike, what do you think is the best solution here? We could use Dominique's
patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46936
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
--- Comment #10 from Brooks Moses brooks at gcc dot gnu.org ---
Author: brooks
Date: Thu Sep 12 23:07:32 2013
New Revision: 202544
URL: http://gcc.gnu.org/viewcvs?rev=202544root=gccview=rev
Log:
PR driver/42955
* Makefile.in: Do not install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #3 from Brooks Moses brooks at gcc dot gnu.org ---
Thanks, Joseph. This is a straightforward Linux target using glibc, so I'll
investigate to see why the binary in question is relying on libssp rather than
glibc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #1 from Brooks Moses brooks at gcc dot gnu.org ---
Jakub, I added you to the cc list in hopes that you may be able to comment on
the original reasoning for this being a runtime check rather than simply a
check for the ability to link
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
The libssp configure script contains a check for whether vsnprintf is usable,
starting around line 128.
This check is based on an AC_RUN_IFELSE call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #4 from Brooks Moses brooks at gcc dot gnu.org ---
It turns out that we do need these symbols in libssp despite having a nice
plain x86-Linux environment. We've got some precompiled blobs from
who-knows-where that want the LIBSSP_1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
--- Comment #8 from Brooks Moses brooks at gcc dot gnu.org ---
FWIW, there was some interesting discussion of this on
http://sourceware.org/bugzilla/show_bug.cgi?id=15823.
In particular, Joseph Myers argues that the bug is installing the files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
--- Comment #9 from Brooks Moses brooks at gcc dot gnu.org ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00490.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2010-04-22 20:17:36 |2013-07-26 20:17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #12 from Brooks Moses brooks at gcc dot gnu.org ---
(In reply to Paulo J. Matos from comment #11)
A non-bug? If you write a memcpy function by hand and call it memcpy, gcc
replaces the function body by a call to memcpy which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537
--- Comment #3 from Brooks Moses brooks at gcc dot gnu.org ---
Thanks for the quick fix, Jakub! And congratulations on the auspicious commit
number, as well. :)
: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: brooks at gcc dot gnu.org
The gcc.dg/vect/slp-widen-mult-half.c test tests autovectorization of this
inner loop:
for (i = 0; i N/2; i++)
{
out[2*i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56334
Bug #: 56334
Summary: __attribute__((aligned)) documentation is outdated and
misleading.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56334
--- Comment #2 from Brooks Moses brooks at gcc dot gnu.org 2013-02-15
01:17:47 UTC ---
(In reply to comment #1)
No, 33721 is about stack variables and not static allocated variables which
still is limited by the linker.
Ah, I missed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56334
--- Comment #3 from Brooks Moses brooks at gcc dot gnu.org 2013-02-15
01:31:23 UTC ---
As a note, the See your linker documentation phrase also occurs in the
function-attributes documentation
(http://gcc.gnu.org/onlinedocs/gcc/Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335
Bug #: 56335
Summary: Optimization assumes __attribute__((aligned(N)))
always works.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337
Bug #: 56337
Summary: __attribute__((aligned(N))) allows too-high values of
N
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337
--- Comment #1 from Brooks Moses brooks at gcc dot gnu.org 2013-02-15
07:06:45 UTC ---
Note that pr39323-2.c tests a closely-related case that presumably is working
correctly:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/pr39323
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830
Bug #: 55830
Summary: inline and __attribute__((always_inline)) treated
differently for unused-function warning
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830
--- Comment #2 from Brooks Moses brooks at gcc dot gnu.org 2012-12-30
21:46:02 UTC ---
Created attachment 29064
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29064
Minimal test case
The attached test case illustrates the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830
--- Comment #3 from Brooks Moses brooks at gcc dot gnu.org 2012-12-30
21:50:08 UTC ---
Andrew: Oh, interesting. So perhaps this is really a failure to warn (or
error?) for a case where __attribute__((always_inline)) isn't used with
inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
Brooks Moses brooks at gcc dot gnu.org changed:
What|Removed |Added
CC||brooks at gcc dot
60 matches
Mail list logo
