Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 47586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47586&action=edit
Source showing problem.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93143
--- Comment #1 from Lars Gullik Bjønnes ---
Forgot to mention that it works nicely with GCC 9.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 47644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47644&action=edit
Source showing the ICE
g++ (GCC) 10.0.0 20200111 (experimental) (f
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 31304
--> http://gcc.gnu.org/bugzi
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
g++ (GCC) 4.9.0 20131128 (experimental)
Copyright (C) 2013 Free
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
This is with gcc --version
gcc (GCC) 4.9.0 20140103 (experimental
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 45635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45635&action=edit
Reduced sources showing ICE
With the attached reduced from cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814
--- Comment #10 from Lars Gullik Bjønnes ---
(In reply to David Malcolm from comment #8)
> Sorry about the breakage.
>
> Here's a candidate patch:
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01133.html
This fixes the ICE for me, with the
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 45675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45675&action=edit
Soruce that works with gcc
++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 44764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44764&action=edit
Source file showing the problem
When I compile the attached code I get this ICE:
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 44771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44771&action=edit
Source showing error
Using g++ -v
Using built-in specs.
COLL
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Compiling this snippet:
class Foo {
public:
explicit Foo(bool)
{}
};
class Bar {
public:
Bar()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970
--- Comment #3 from Lars Gullik Bjønnes ---
The warning might be right, but is very unhelpful.
Also with gcc 5 I get no warning (and seeming working code).
Note that this is reduced (and thus a bit strange) from a much
larger code base.
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
In Eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page),
this construct is used to group things:
void do_stuff();
void do_other_stuff();
int main
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
When looking at n3793 it states that operator!= should be implemented
with !(t1 == t2), and not t1 != t2 as the implementation in gcc 4.9 is
doing. This is the case for both the operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710
Lars Gullik Bjønnes changed:
What|Removed |Added
CC||larsbj at gullik dot net
++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Created attachment 32707
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32707&action=edit
gzipped preprossed code showing the problem
In current trunk I get some new strict-aliasing warnings tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
--- Comment #7 from Lars Gullik Bjønnes ---
(In reply to Richard Biener from comment #6)
> Created attachment 32713 [details]
> untested patch
This fixes the problem for me, in my
application.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Created attachment 33004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33004&action=edit
Preprosessed file
When compiling a test file consisting of only a
#include
line. I get the following ICE:
: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Created attachment 31897
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31897&action=edit
Reduced preprocessed code.
g++ --version
g++ (GCC) 4.9.0 20140120 (experimental) as of rev 206794
When compiling the a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
Lars Gullik Bjønnes changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
--- Comment #3 from Lars Gullik Bjønnes ---
Yes, the compiler is built with:
../gcc/configure --prefix=/opt/gcc/gcc-trunk --enable-checking=release
--enable-languages=c,c++,lto
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
--- Comment #1 from Lars Gullik Bjønnes ---
Command used to call:
gcc -fsanitize=undefined -fgnu-tm tm-thread.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218
Lars Gullik Bjønnes changed:
What|Removed |Added
CC||larsbj at gullik dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64314
--- Comment #2 from Lars Gullik Bjønnes ---
I still see this, but with current gcc5 the call stack has become a bit
deeper, instead of 5 calls to walk_tree_1 I now see 9 calls.
(with -std=gnu++14 in this case.)
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
With this test program I get an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984
--- Comment #4 from Lars Gullik Bjønnes ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 34710 [details]
> gcc5-pr64984.patch
>
> Untested fix.
This seems to fix ICE, but I have at least one more that needs tracking down,
al
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
With this test program I get an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
--- Comment #3 from Lars Gullik Bjønnes ---
This is a different code snippet to get what seems to be the same error:
---
#include
int f(unsigned int datalen);
class Streambuf : public std::basic_streambuf {
private:
virtual in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
--- Comment #4 from Lars Gullik Bjønnes ---
Created attachment 34712
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34712&action=edit
preprocesed source for second code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
--- Comment #2 from Lars Gullik Bjønnes ---
Created attachment 34711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34711&action=edit
preprocessed source for test code in #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65000
--- Comment #7 from Lars Gullik Bjønnes ---
Note that my last tests is done with the proposed fix for
bug 64984 applied.
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
With:
gcc (GCC) 5.0.0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Compiling this:
#include
enum profile_type {};
struct A {
std::string value;
};
struct {
profile_type type;
A strategies[1];
} a{};
with:
g++ -std=gnu++1 -c
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
$ cat main.ii
struct Test {
Test();
};
Test::Test()
{
int w = 512;
unsigned rgb_ref[1][w];
}
Gives this error:
$ /opt/gcc/gcc-trunk/bin/g++ -c
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
cat aligned_alloc.c
#include
int main(void)
{
void
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: larsbj at gullik dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target
--- Additional Comments From larsbj at gullik dot net 2005-01-03 16:22
---
Just a comment before I begin work to create a testcase that is abit smaller
than
the whole lyx distribution. If I turn off concept checks the ICE goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From larsbj at gullik dot net 2005-01-03 18:25
---
Ok, do you want a tar file with the setup to reproduce or do you want me to
attach ~100 attachments to this case with all the files needed to reproduce?
And reading gcc.gnu.org does not make it easier to create
--- Additional Comments From larsbj at gullik dot net 2005-01-03 19:21
---
I get a bit further with that, but I am not able to reproduce the error with
the resulting .ii file together with the pch.h (and pch.h.gch) file.
Instead I get stuck with myriads or errors similar to these
--- Additional Comments From larsbj at gullik dot net 2005-01-03 19:56
---
Then I am at a loss. I am only able to reproduce with the full lyx tree, when
using the preprocessed files I get errors about 'std' not being defined. (etc)
How did you compile the preprocessed sources
--- Additional Comments From larsbj at gullik dot net 2005-01-03 20:19
---
(In reply to comment #11)
> grep -v ^# FormExternal.ii> FormExternal.cc
> gcc FormExternal.cc -include pch.ii
ok, my mistake was using g++ instead. Using the above I to get a clean compile
(-c). So it
--- Additional Comments From larsbj at gullik dot net 2005-01-03 20:22
---
(In reply to comment #12)
> ok, my mistake was using g++ instead.
Not having done the "grep" more likely, and trying to compile the .ii file
directly.
--
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From larsbj at gullik dot net 2005-01-03 20:28
---
(In reply to comment #12)
>
> > grep -v ^# FormExternal.ii> FormExternal.cc
> > gcc FormExternal.cc -include pch.ii
>
> So it is quite obvious that just using preprocessed sources will
--
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed||1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19241
--- Additional Comments From larsbj at gullik dot net 2005-01-05 18:14
---
(In reply to comment #17)
> Lars, can you maybe describe how to reproduce this starting from the lyx
> tarball? (I.e. which tarball to download, how to configure so that it uses
> PCH
> etc.)
--- Additional Comments From larsbj at gullik dot net 2005-01-29 19:09
---
This does not seem to be fixed so reopening.
--
What|Removed |Added
CC
--
What|Removed |Added
CC||larsbj at gullik dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
Lars Gullik Bjønnes changed:
What|Removed |Added
CC||larsbj at gullik dot net
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
Target Milestone: ---
Created attachment 53936
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53936&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104017
--- Comment #6 from Lars Gullik Bjønnes ---
This is from a report I made in private to Martin, for GCC12.
That tidbit seems to have been lost in the bug creation.
52 matches
Mail list logo
