https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
Bug ID: 69863
Summary: no_sanitize_address doesn't disable stack
instrumentation
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Feb 18 08:43:58 2016
New Revision: 233516
URL: https://gcc.gnu.org/viewcvs?rev=233516&root=gcc&view=rev
Log:
2016-02-18 Richard Biener
PR middle-end/69854
* mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67767
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #53 from Richard Biener ---
I have a simple patch :P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
--- Comment #1 from Jakub Jelinek ---
I think the right fix is to add the
&& !lookup_attribute ("no_sanitize_address", DECL_ATTRIBUTES
(current_function_decl)) check next to the && ASAN_STACK checks (perhaps even
put
(flag_sanitize & SANITIZE_ADD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69862
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272
Jonathan Wakely changed:
What|Removed |Added
CC||philippeb8 at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #6 from Markus Trippelsdorf ---
Created attachment 37728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37728&action=edit
unreduced testcase
trippels@gcc2-power8 llvm_build % g++ -Wnonnull-compare -Werror -c
VariantValue.ii
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
--- Comment #4 from David Binderman ---
(In reply to ktkachov from comment #3)
> Agree that gcc should warn here.
> As for the suspicious return itself, from what I can see it has the effect
> of overly restricting generation of the LDRD/STRD ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
--- Comment #5 from ktkachov at gcc dot gnu.org ---
We'd need a testcase that shows a regression resulting from this code not being
run i.e. code that became worse after r197530 (or wrong code or an ICE) and is
fixed by removing that "return false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
Sergio Martins changed:
What|Removed |Added
CC||gcc at bobbyperu dot info
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Bug ID: 69864
Summary: Narrowing conversion
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
--- Comment #6 from David Binderman ---
(In reply to ktkachov from comment #5)
> We'd need a testcase that shows a regression resulting from this code not
> being run i.e. code that became worse after r197530 (or wrong code or an
> ICE) and is fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
--- Comment #1 from mgsergio ---
*gcc emits a warning on narrowing_check although an error should be generated
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, that's an approach that can be taken. Once such a case is found, you could
also try using a reducer program like creduce to create a small testcase
appropriate for the testsuite.
Removing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764
--- Comment #11 from Andreas Schwab ---
/daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
-B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
-B/daten/cross/m68k-linux/m68k-linux/bin/
-B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
/daten/cross/m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764
--- Comment #12 from Jakub Jelinek ---
(In reply to Andreas Schwab from comment #11)
> /daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
> -B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
> -B/daten/cross/m68k-linux/m68k-linux/bin/
> -B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764
--- Comment #13 from Andreas Schwab ---
Created attachment 37729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37729&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69849
--- Comment #1 from vries at gcc dot gnu.org ---
In addition, the '%{%:function(args):X}' construct is undocumented, as noted
here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01243.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764
--- Comment #14 from Jakub Jelinek ---
Doesn't ICE for me...
Can you please debug what is going on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #24 from Kirill Yukhin ---
(In reply to rguent...@suse.de from comment #23)
> On Wed, 17 Feb 2016, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
> >
> > --- Comment #22 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #25 from Jakub Jelinek ---
I've already posted the patch for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01201.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580
--- Comment #11 from vries at gcc dot gnu.org ---
Alternative patch proposed by Bernd Edlinger :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00976.html .
Patch approved by sanitizer reviewer :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #43 from alalaw01 at gcc dot gnu.org ---
Yeah, I plan to add a fortran-specific option for this, it's easy enough, but I
can't run the gfortran testsuite with that, because there are lots of C files
in there too, for which the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
--- Comment #2 from Jonathan Wakely ---
Minimal reproducer:
int get();
void f() {
char get();
}
Slightly sneakier version that defeated my first attempt to fix it (because the
overload set causes us to discard the previous decls):
int get();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69819
--- Comment #5 from Marek Polacek ---
This fixes it but I'd like to think about this some more.
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -4743,7 +4743,7 @@ finish_decl (tree decl, location_t init_loc, tree init,
struct c_binding *b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #7 from Markus Trippelsdorf ---
(wow, llvm approaches Boost in the complexity of testcases. It takes ages to
reduce them.)
class RefCountedBaseVPTR {
virtual ~RefCountedBaseVPTR();
void Release() const { delete this; }
templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69844
--- Comment #1 from Marek Polacek ---
I think a safe fix would be to just add if (!c_dialect_objc ()) to the change
that caused this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
Bug ID: 69865
Summary: -trigraphs option broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69610
--- Comment #3 from Nick Clifton ---
Author: nickc
Date: Thu Feb 18 13:00:07 2016
New Revision: 233518
URL: https://gcc.gnu.org/viewcvs?rev=233518&root=gcc&view=rev
Log:
PR target/62554
PR target/69610
gcc * config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
Nick Clifton changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #1 from Bernd Edlinger ---
weird:
If I add -std=c++14 (or any other c++ version, including -ansi)
to the command line, it works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #44 from Thomas Koenig ---
I don't have access to SPEC, so I can only guess...
Is there maybe an equivalence involved, something like
COMMON /FOO/ X(1)
EQUIVALENCE (X,Y)
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #8 from Jakub Jelinek ---
Created attachment 37730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37730&action=edit
gcc6-pr69850.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #45 from Jakub Jelinek ---
Consider e.g. one source file
INTEGER FOO
COMMON /BLK/ K(64)
DO I=1,64
K(I)=1
END DO
IF (FOO(5,12).NE.51) CALL ABORT
END
and another one:
FUNCTION FOO(I, J)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #46 from rguenther at suse dot de ---
On Thu, 18 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #45 from Jakub Jelinek ---
> Consider e.g. one source file
> INTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #48 from rguenther at suse dot de ---
On Thu, 18 Feb 2016, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #46 from rguenther at suse dot de ---
> On Thu, 18 Feb 2016, jakub at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #47 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #46)
> Which is odd since FRE already should optimize it that way.
Bet FRE punts on that because it considers it poor man's flexible array member.
But, you know F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #49 from Dominique d'Humieres ---
> Yeah, I plan to add a fortran-specific option for this, it's easy enough,
I don't see the point to add yet another option just because "SPEC does not
want to change the invalid Fortran". I think SP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #10 from Markus Trippelsdorf ---
Still happening even with latest patch:
[1763/2142] Building CXX object
tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/clangStaticAnalyzerCore.dir/HTMLDiagnostics.cpp.o
In file included from
/home/tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
--- Comment #2 from Bernd Edlinger ---
in gcc/c-family/c-opts.c:
following code in line 805:
/* Set C++ standard to C++14 if not specified on the command line. */
if (c_dialect_cxx () && cxx_dialect == cxx_unset)
set_std_cxx14 (/*ISO*/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #11 from Jakub Jelinek ---
Can you attach it again?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #12 from Markus Trippelsdorf ---
Created attachment 37731
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37731&action=edit
unreduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
Manuel López-Ibáñez changed:
What|Removed |Added
CC||mgsergio at yandex dot ru
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #13 from Markus Trippelsdorf ---
template struct A {
static void release(T *p1) { p1->Release(); }
};
template class IntrusiveRefCntPtr {
T Obj;
public:
void operator=(IntrusiveRefCntPtr) { A::release(&Obj); }
};
struct RopeRe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553
--- Comment #11 from Richard Biener ---
Author: rguenth
Date: Thu Feb 18 14:34:59 2016
New Revision: 233520
URL: https://gcc.gnu.org/viewcvs?rev=233520&root=gcc&view=rev
Log:
2016-02-18 Richard Biener
PR middle-end/69553
* fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #50 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #51 from rguenther at suse dot de ---
On Thu, 18 Feb 2016, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> H.J. Lu changed:
>
>What|Removed |Added
> --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 14:49:16 2016
New Revision: 233521
URL: https://gcc.gnu.org/viewcvs?rev=233521&root=gcc&view=rev
Log:
PR c++/68679
* decl2.c (reset_type_linkage_2): Look throug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 14:49:22 2016
New Revision: 233522
URL: https://gcc.gnu.org/viewcvs?rev=233522&root=gcc&view=rev
Log:
PR c++/68585
* constexpr.c (cxx_eval_bare_aggregate): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #52 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #51)
> > --- Comment #50 from H.J. Lu ---
> > Has my fix for 416.gamess source been applied when the failure happened?
>
> No.
So, there is nothing to fix in GCC? Why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000
Tiziano Müller changed:
What|Removed |Added
CC||dev-zero at gentoo dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Jakub Jelinek changed:
What|Removed |Added
Attachment #37730|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #14 from Bernd Schmidt ---
Author: bernds
Date: Thu Feb 18 15:23:11 2016
New Revision: 233523
URL: https://gcc.gnu.org/viewcvs?rev=233523&root=gcc&view=rev
Log:
Backport PR69648 fix from mainline (set of picreg removed during lra).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #53 from alalaw01 at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #44)
> I don't have access to SPEC, so I can only guess... Is there maybe an
> equivalence involved, something like
Turns out the COMMON is accessed via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #15 from Markus Trippelsdorf ---
markus@x4 c++11 % /var/tmp/gcc_build_dir_/./gcc/xgcc -shared-libgcc
-B/var/tmp/gcc_build_dir_/./gcc -nostdinc++
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/var/tmp/gcc_build_dir_/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53086
--- Comment #18 from H.J. Lu ---
Created attachment 37733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37733&action=edit
Fix for 416.gamess in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69844
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
@class D;
void
foo (void)
{
for (;;)
;
D *d = (id) 0;
(void) d;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #54 from H.J. Lu ---
(In reply to alalaw01 from comment #53)
> >
> >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
>
> Not everyone wants to patch SPEC sources.
If the SPEC source is invalid according to F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69663
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69844
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
Bernd Schmidt changed:
What|Removed |Added
Assignee|vmakarov at redhat dot com |bernds at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Bernd Schmidt changed:
What|Removed |Added
Assignee|vmakarov at redhat dot com |bernds at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Thu Feb 18 17:15:25 2016
New Revision: 233524
URL: https://gcc.gnu.org/viewcvs?rev=233524&root=gcc&view=rev
Log:
Do not emit red stack zones for a fn with no_sanitize_address
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #16 from Jakub Jelinek ---
Created attachment 37735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37735&action=edit
gcc6-pr69850-3.patch
Untested incremental fix for the dynamic_cast issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859
Dominique d'Humieres changed:
What|Removed |Added
Keywords||error-recovery,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69668
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Feb 18 18:23:09 2016
New Revision: 233528
URL: https://gcc.gnu.org/viewcvs?rev=233528&root=gcc&view=rev
Log:
2016-02-18 Jerry DeLisle
Backport from gcc-5-branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69668
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
Bug ID: 69866
Summary: lto1: internal compiler error: in
add_symbol_to_partition_1, at lto/lto-partition.c:158
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #8 from Vladimir Makarov ---
(In reply to Michael Meissner from comment #7)
> The following options were used for LRA code generation:
> -DSPEC_CPU -DNDEBUG -I. -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66337
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859
--- Comment #4 from David Malcolm ---
Running under valgrind, it looks like it's a use-after-free error:
$ cat ../../src/z7.f90
program p
type t
character(2), allocatable :: a(*)
character(*), allocatable :: b(2)
character(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867
Bug ID: 69867
Summary: ICE on initializing character in type with array of
incompatible data
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867
--- Comment #1 from Gerhard Steinmetz
---
Detected when lhs is a scalar :
$ cat z4.f90
program p
type t
character(1) :: c(1) = 1
end type
end
$ gfortran-6 z4.f90
z4.f90:3:28:
character(1) :: c(1) = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867
--- Comment #3 from Gerhard Steinmetz
---
These issues are thematically related to pr67804 (... more or less).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867
--- Comment #2 from Gerhard Steinmetz
---
One exception from comment 1 :
$ cat z7.f90
program p
type t
character(1) :: b = null()
character(1) :: c(1) = null()
end type
end
$ gfortran-6 z7.f90
f951: internal compiler error: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #33 from Michael Meissner ---
Author: meissner
Date: Thu Feb 18 19:36:39 2016
New Revision: 233532
URL: https://gcc.gnu.org/viewcvs?rev=233532&root=gcc&view=rev
Log:
[gcc]
2016-02-18 Michael Meissner
PR target/68404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Michael Meissner changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #35 from Michael Meissner ---
Author: meissner
Date: Thu Feb 18 19:59:03 2016
New Revision: 233535
URL: https://gcc.gnu.org/viewcvs?rev=233535&root=gcc&view=rev
Log:
Merge in fix for PR 68404
Modified:
branches/ibm/power9/ (pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868
Bug ID: 69868
Summary: vec_perm built-in is not handled by swap optimization
on powerpc64le
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69867
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #55 from Jerry DeLisle ---
(In reply to H.J. Lu from comment #54)
> (In reply to alalaw01 from comment #53)
> > >
> > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> >
> > Not everyone wants to patch SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #56 from Dominique d'Humieres ---
> > FUNCTION FOO(I, J)
> > COMMON /BLK/ K(1)
> > FOO = K(I) + K(J) + K(2*I) + K(2*J)
> > END FUNCTION
This piece of code is also invalid (out of bound access to K): K(I) + K(J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812
--- Comment #2 from Geir Johansen ---
(In reply to Jakub Jelinek from comment #1)
> You haven't said which target it is, and we need preprocessed source as well.
> Couldn't reproduce this on x86_64-linux.
Problem does not occur in GCC 4.9.0, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60812
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
1 - 100 of 113 matches
Mail list logo
