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, in
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 that
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 war
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 a
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
--- Comme
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 dup
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 ta
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 #13 from Brooks Moses ---
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
--- Comment #12 from Brooks Moses ---
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? The wide_int pieces don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment
Status: UNCONFIRMED
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 (0) = 0)> int
break_it();
template int break_it();
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144
--- Comment #4 from Brooks Moses ---
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 ---
Ping? Any updates on this?
ity: minor
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) { }
NCONFIRMED
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=33328&action=edit
(Exam
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=33316&action=edit
Small example program.
(Google ref: b/17007254)
The fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
--- Comment #8 from Brooks Moses ---
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<>::;
= int; _Res = std::A;
||brooks at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #7 from Brooks Moses ---
This testcase is failing again on trunk at r213772.
Severity: 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
int foo(uin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
--- Comment #15 from Brooks Moses ---
(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 that this fixes the
failures I wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
--- Comment #11 from Brooks Moses ---
(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 to change things. S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #9
atus: 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::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #8 from Brooks Moses ---
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 to test the latest ABI version
rmal
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 K&R-style function definitions
that's causing some various old GNU software to fail in some cas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #4 from Brooks Moses ---
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 with a comment to the effect that "New-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #6
||brooks at gcc dot gnu.org
Resolution|--- |MOVED
--- Comment #4 from Brooks Moses ---
This appears to be a local issue with the google/* branches. It's now been
reported internally at Google, and I'm closing this since it doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46936
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
Brooks Moses changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
--- Comment #10 from Brooks Moses ---
Author: brooks
Date: Thu Sep 12 23:07:32 2013
New Revision: 202544
URL: http://gcc.gnu.org/viewcvs?rev=202544&root=gcc&view=rev
Log:
PR driver/42955
* Makefile.in: Do not install driver binaries in $(target)/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #4 from Brooks Moses ---
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" version of the __vsnprin
Severity: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #1 from Brooks Moses ---
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 a program calling vsnprintf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312
--- Comment #3 from Brooks Moses ---
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=42955
--- Comment #9 from Brooks Moses ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00490.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
--- Comment #8 from Brooks Moses ---
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 in
$target/bin/ at all ...
||brooks at gcc dot gnu.org
Severity|normal |critical
--- Comment #7 from Brooks Moses ---
I have reconfirmed this, in the following things, all for different targets:
* A downloaded Sourcery CodeBench Lite Edition 2010.09 (GCC 4.5.1 with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #12 from Brooks Moses ---
(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 generates an infinite
> loop. Ho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57537
--- Comment #3 from Brooks Moses ---
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[
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56337
--- Comment #1 from Brooks Moses 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-2.c?view=markup
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=56335
Bug #: 56335
Summary: Optimization assumes __attribute__((aligned(N)))
always works.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56334
--- Comment #3 from Brooks Moses 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-Attributes.html).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56334
--- Comment #2 from Brooks Moses 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 that. That makes sense.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Brooks Moses changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
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: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830
--- Comment #3 from Brooks Moses 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", and a case of missin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830
--- Comment #2 from Brooks Moses 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. When compiled with -Wall
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=27557
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #6
60 matches
Mail list logo
