mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
Created attachment 37669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37669&action=edit
Preprocessed source
The code below compiles+runs fine on gcc 4.7,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69774
--- Comment #1 from Guille ---
Note that the problem persists if we pass by reference in the lambda, i.e.
using
"t = [&] { std::cerr << &a << " \n"; };"
instead of
"t = [this] { std::cerr << &a << " \n"; };".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69774
Guille changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
I'm getting ICEs on any call to c++ with option '-Wno-aligned-new'
(Incidentally, overaligned structs can be allocated with 'new' using option
'-faligned-new&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77651
--- Comment #2 from Guille ---
Correction: There is no issue with '-faligned-new', only with
'-Wno-aligned-new'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77651
--- Comment #3 from Guille ---
Excuses, I take that back.
I use placement new on a properly aligned piece of memory, gcc complains
(warning) that:
* 'note: uses ‘void* operator new(std::size_t, void*)’, which does not have an
alignment paramet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77651
--- Comment #4 from Guille ---
For what it's worth, any call to 'c++ -Waligned-new=none ...' will also ICE.
: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
The following short program ICEs in c++ '7.0.0 20161106' (ICE goes away if we
eliminate the default-initialized parameter):
#include
#include
inline void f(struct tm time_tm = {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78369
--- Comment #2 from Guille ---
Yes, somehow I get ICE with -std=c++1z but not without it.
Here's 'c++ -v'
***
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
The following code does not compile on 5.2.0:
struct A {};
struct B {};
static auto f(auto b) -> A { return A(); }
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
--- Comment #1 from Guille ---
Ignore "__attribute__((unused))", it was added by mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
--- Comment #2 from Guille ---
struct A {};
struct B {};
static auto f(auto b) -> A { return A(); } // error: could not convert 'A()'
from 'A' to 'B'
int main()
{
A a = f(B()); // error: conversion from 'B' to non-scalar type 'A'
requeste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
--- Comment #3 from Guille ---
gcc 5.2.0: -Wall -Wextra -std=c++1y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
--- Comment #5 from Guille ---
(In reply to Marc Glisse from comment #4)
> This seems to be already fixed on trunk.
Just tested on most recent gcc version 5.2.1 20151006 (GCC) and it doesn't
compile:
t.c: In function ‘int main()’:
t.c:10:12: e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
--- Comment #6 from Guille ---
Can confirm it does compile on gcc version 6.0.0 20151004.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67910
Guille changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
rsion: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67917
Guille changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
Created attachment 36709
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36709&action=edit
this is the OSX 10.9.5 /usr/include/openssl/ssl.h
t.c:
#include
int main() { return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351
--- Comment #2 from Guille ---
Created attachment 36710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36710&action=edit
This is the preprocessed file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #18 from Guille ---
I may be missing something: I could build latest openssl no problem, but
'#include \int main(){return 0;}' ICEs on my system's installed
openssl (OSX 10.9.5).
(In reply to Magnus Fromreide from comment #16)
> Sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #20 from Guille ---
(In reply to Magnus Fromreide from comment #19)
> When you say "latest openssl", do you refer to trunk or 1.0.2d? It seems
> that the problem is gone from openssl trunk due to a source reorganization
> but it seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #22 from Guille ---
For what it's worth, I just checked again openssl-1.0.2d builds fine with 'gcc
6.0.0 20151108' on OSX 10.9.5.
Checked it is running the right gcc (both with and without '-g'), configured
with 'darwin-i386-cc' and '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #24 from Guille ---
Yes, just checked that.
'gcc -g file_that_include_ssl_h.cpp' builds fine, but
'g++ -g file_that_include_ssl_h.cpp' ICEs.
(In reply to Magnus Fromreide from comment #23)
> One more question - you are using the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #26 from Guille ---
In the case below (fails to compile ssl.h on OSX 10.9.5),
I could simply go to ssl.h lines 337 and 339 and comment out the
'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER'..
then it compiled no problem.
(In r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #27 from Guille ---
(In reply to Guille from comment #26)
> In the case below (fails to compile ssl.h on OSX 10.9.5),
> I could simply go to ssl.h lines 337 and 339 and comment out the
> 'DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272
Guille changed:
What|Removed |Added
CC||guille at cal dot berkeley.edu
--- Comment #3
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
Created attachment 36950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36950&action=edit
Preprocessed source
Multiplying:
_mm256_mul_epi32([1,1,1,1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68780
Guille changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
The following two assertions fail:
#include
#include
#include
std::set all;
struct A
{
A()
{
all.insert((std::uintptr_t)this);
}
~A()
{
assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71786
--- Comment #1 from Guille ---
I should note, the destructor *is* called, but not the constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71786
--- Comment #2 from Guille ---
I added some printing-code to it. This is what I get:
A() -> INSERT: 0x7fff5c44cb2f
~A() -> ERASE: 0x7fff5c44cb2f
~A() -> ERASE: 0x7fff5c44cb40
Assertion failed: (!all.empty()), function ~A, file gcc_bug.c, line 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71786
--- Comment #4 from Guille ---
Hi Marc,
Thank you for your clarification.
I realized my initial problem arose in a slightly more complicated case
(below).
In this case a copy/move ctor of A is used, but this default-generated ctor
does not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71786
--- Comment #5 from Guille ---
Sorry for the confusion, I'll post as a separate report for clarity.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at cal dot berkeley.edu
Target Milestone: ---
The following code (below) fails.
The output of the program is:
B() -> INSERT: 0x7fff570c8b2f
~B() -> ERASE: 0x7fff570c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71804
--- Comment #2 from Guille ---
(In reply to Marc Glisse from comment #1)
> This is not the right place to learn about C++. Before filing a bug report
> about a compiler, please find another compiler that behaves differently. If
> all compilers be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71804
--- Comment #3 from Guille ---
Sorry, this was silly. I'll try to get some sleep before posting something at
5am.
37 matches
Mail list logo
