https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67856
--- Comment #4 from Andy Lutomirski ---
I don't want to comment on how code generation works in GCC, but in terms of
what works in the output:
x86_64 generally has a 16-byte stack alignment in user code, which is two
slots. (In the kernel, we u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67856
--- Comment #2 from Andy Lutomirski ---
(In reply to Segher Boessenkool from comment #1)
> The call to "a" needs the prologue, maybe to align the stack?
The "subq $8, %rsp" is for stack alignment, and whether it's emitted depends on
the parity o
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
Target Milestone: ---
This code:
typedef _Bool bool;
extern int a(void);
/* used as a proxy for real code. */
volatile int x;
bool func(void *regs)
{
int t1, t2, t3, t4, t5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #17
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
Target Milestone: ---
Here's an evil little program (x86_64-specific, although I suspect that a
trivial change would have the same effect on x86_32):
#include
#in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #21 from Andy Lutomirski ---
(In reply to H.J. Lu from comment #20)
> (In reply to Andy Lutomirski from comment #19)
> > I don't think the fix is correct.
> >
> > This works:
> >
> > gcc -mno-sse -mpreferred-stack-boundary=3 ...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61129
Andy Lutomirski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500
--- Comment #4 from Andy Lutomirski ---
Created attachment 33485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33485&action=edit
Output from g++ -O2 -Wall -fdump-tree-all-all-lineno pr59500.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500
--- Comment #3 from Andy Lutomirski ---
Created attachment 33484
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33484&action=edit
Headerless reproducer (c++ only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
--- Comment #10 from Andy Lutomirski ---
See PR59500 for another example without &&. I think I can reduce another test
case with only if and else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #7
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
Clang has a fairly complete family of intrinsics to do integer arithmetic with
overflow detection. They include function like __builtin_uadd_overflow, and
they
: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
This little program:
int main()
{
char buf[4096];
memcpy(buf, (void *)0xff60, 4096);
return 0;
}
does this:
$ gcc ice.c
ice.c: In function ‘main’:
ice.c:4:3: warning: incompatible implicit declaration of built-in
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
namespace NS {
template
class Holder
{
private:
void func();
template
friend class User;
};
template class Holder;
template
class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58116
--- Comment #4 from Andy Lutomirski ---
Sorry -- I forgot about the recursive / threaded case.
(I keep meaning to propose something like [[non_unique_address]] to enable
optimizations like this and things zero-byte struct members.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500
--- Comment #1 from Andy Lutomirski ---
This might be a duplicate of PR56574
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
I would have sworn that there was a bug open about this, but I can't find it,
and this bug has been annoying me for years.
Compiling this code with g++ -O2 -Wall:
#ifndef __cplusplus
#in
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
This program:
extern void func(void);
extern __inline __attribute__((__always_inline__))
__attribute__((__gnu_inline__)) void func(void) { }
extern void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #12 from Andy Lutomirski ---
D'oh! I assumed that "it" was the resulting library (and thus that it would
require linking *against librt*), not that "it" was the configure test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #9 from Andy Lutomirski ---
Given that this is C++11-only, it's already fixed on trunk, it's only a
performance issue (as opposed to correctness), and it's more complicated than
just changing the default, I won't argue for a backport.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #7 from Andy Lutomirski ---
I guess what I'm saying is: what's wrong with "yes" in 4.8? From looking at
the code, it still seems like it does the right thing (i.e. not using
clock_gettime if it's not in [posix4]).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
Andy Lutomirski changed:
What|Removed |Added
Version|4.9.0 |4.8.3
--- Comment #5 from Andy Lutomirs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #3 from Andy Lutomirski ---
I can't get gcc trunk to build right now, but I just distcleaned and rebuilt
the 4.8 branch truck on Fedora 19, which has glibc-2.17-19.fc19.x86_64. It
defines _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL. This happ
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
std::chrono::steady_clock::now() does this:
#ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL
syscall(SYS_clock_gettime, CLOCK_MONOTONIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #9
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
This code:
struct S
{
int a, b, c;
};
extern void callee(const S &s);
void test()
{
const S s{1,2,3};
callee(s);
callee((const S){1,2,3});
}
woul
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
When trying and failing to move an object because the move constructor is
deleted, the error message tells you so. When there is no move constructor at
all, however
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
[This is fixed in trunk. If the stable branch policy means it can't get
backported, then so be it. I'm filing the bug because this issue is *really*
annoying.]
This erroneous code:
// Addi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Andy Lutomirski changed:
What|Removed |Added
Summary|rejected valid |Invalid specializations of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #6 from Andy Lutomirski ---
Jonathan Wakely wrote in comment #4:
> (In reply to Andy Lutomirski from comment #4)
>> [temp.explicit].4 says "A declaration of [list including member function]
>> ... A definition of [list not including me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #4 from Andy Lutomirski ---
Daniel, I'm unconvinced that your interpretation is the intended one.
[temp.explicit].4 says "A declaration of [list including member function] ... A
definition of [list not including member function]". If
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
Note: I could easily be wrong here...
template
struct X
{
static int val;
static void func();
};
extern template struct X;
template<> int X::v
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
It's well known [citation needed] that modern compilers are excellent at
optimizing simple bit twiddling. Unfortunately, while gcc is, g++ is not.
(See PR29749 for where gcc gained this ability.)
H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527
--- Comment #1 from Andy Lutomirski 2013-03-05 00:37:20
UTC ---
In fact, without an improvement like this, protected visibility is unusable on
objects -- anything linking against a protected object will generate a copy
relocation. The fac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56527
Bug #: 56527
Summary: Provide an import counterpart to
attribute((visibility("protected")))
Classification: Unclassified
Product: gcc
Version: unknown
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #3 from Andy Lutomirski 2012-11-30 01:41:14
UTC ---
I'm still unconvinced that it makes sense as part of
-funsafe-math-optimizations at all. It's not an "optimization" in the sense
that people usually think of when looking at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55540
--- Comment #2 from Andy Lutomirski 2012-11-29 22:58:44
UTC ---
Gack.
I'm still at a loss as to where __int128 is coming from. I don't think it's an
integral promotion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55540
Bug #: 55540
Summary: The C++ literal -9223372036854775808 is misinterpreted
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #1 from Andy Lutomirski 2012-11-29 01:48:53
UTC ---
I mean IEEE754, of course.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Bug #: 55522
Summary: -funsafe-math-optimizations is unexpectedly harmful,
especially w/ -shared
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55347
Bug #: 55347
Summary: Specialized member of class template prevents
visibility setting
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55307
Bug #: 55307
Summary: libgcc's __cpu_indicator_init does not check for avx
correctly
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55029
Bug #: 55029
Summary: constexpr bug: lvalue required?
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021
--- Comment #8 from Andy Lutomirski 2012-09-09 06:05:34
UTC ---
Did you mean "constexpr bool a" instead of "book const a"? If so, I agree.
But consider:
bool const a = something complicated
Is a a constant?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021
--- Comment #6 from Andy Lutomirski 2012-09-08 22:29:17
UTC ---
I think that's correct. x isn't a standards-mandated constant expression, so
__builtin_constant_p depends on optimization level and probably shouldn't be
allowed as a constexpr.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54336
--- Comment #2 from Andy Lutomirski 2012-08-20 23:21:32
UTC ---
Fair enough. Here's a better example:
struct A { int method(); };
template auto func(T x) -> decltype(x.method())
{
bogus(x);
}
int main() { func(A()); }
The error is:
declty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54336
Bug #: 54336
Summary: [c++0x] diagnostics for functions with arg-dependent
return types have bad signatures
Classification: Unclassified
Product: gcc
Version: 4.8.0
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54020
--- Comment #2 from Andy Lutomirski 2012-07-19 15:41:51
UTC ---
I clearly failed at reading comprehension yesterday.
Maybe this should be considered as more of an enhancement request (like
PR54021): it would be nicer for the user if constexpr wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021
Bug #: 54021
Summary: [c++0x] __builtin_constant_p should be constexpr
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54020
Bug #: 54020
Summary: [c++0x] incorrectly accepted constexpr functions
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53582
Bug #: 53582
Summary: [4.6 regression, fixed in 4.7, I think] ICE on valid
code
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53561
Andy Lutomirski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53561
Bug #: 53561
Summary: [c++0x] regex_replace is missing overloads
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53465
Bug #: 53465
Summary: [4.7 regression] wrong code with -O1 -ftree-vrp
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234
Bug #: 53234
Summary: [c++0x] unfriendly error message for missing move
constructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53223
--- Comment #4 from Andy Lutomirski 2012-05-03 23:25:54
UTC ---
PR51547 could be the same thing. I'll build and test trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53223
--- Comment #2 from Andy Lutomirski 2012-05-03 23:21:10
UTC ---
(In reply to comment #1)
> Don't we have something in Bugzilla about auto && ?
There's PR 52851, but that's supposedly fixed in 4_7-branch, and (unless I
messed up) this bug is pres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53223
Bug #: 53223
Summary: [c++0x] auto&& and operator* don't mix inside
templates
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494
Andy Lutomirski changed:
What|Removed |Added
CC||luto at mit dot edu
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53097
Bug #: 53097
Summary: [c++0x] Missed optimization: lambda closure object
could be smaller
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51777
Bug #: 51777
Summary: Errors message show unsigned long template parameters
as signed
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51556
--- Comment #4 from Andy Lutomirski 2011-12-15 00:00:18
UTC ---
Created attachment 26095
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26095
Partially reduced test case
This is reduced by a combination of fiddling by hand and automated red
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51556
--- Comment #2 from Andy Lutomirski 2011-12-14 20:30:01
UTC ---
Created attachment 26088
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26088
Preprocessed test cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51556
--- Comment #1 from Andy Lutomirski 2011-12-14 20:28:28
UTC ---
Created attachment 26087
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26087
Working test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51556
Bug #: 51556
Summary: Bizarre member template protection errors
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51348
Bug #: 51348
Summary: [c++0x] ICE in finish_class_member_access_expr with
bogus(?) enum class use
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641
--- Comment #4 from Andy Lutomirski 2011-10-07 06:57:01
UTC ---
The problem I encountered that inspired this was:
#include
#include
struct From
{
};
struct To
{
To(const From &&) {}
To(const To &) = delete;
void operator = (const To &)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50641
Bug #: 50641
Summary: [c++0x] is_convertible and is_constructible
incorrectly require copy constructibility
Classification: Unclassified
Product: gcc
Version: 4.7.0
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50372
Bug #: 50372
Summary: c++11: pointers to static functions should be valid
template parameters
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48877
Summary: Inline asm for rdtsc generates silly code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46514
Summary: 128-bit shifts on x86_64 generate silly code unless
the shift amount is constant
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority:
73 matches
Mail list logo
